Re: GnuTLS updates proposal

[Stephen J. Turnbull]

Stefan Monnier writes:

 > SM> Now I lost you.  How did we go from "gnutls" to "we"?
 > SM> Shouldn't some gnutls guys take care of that?

No, why should they?  Emacs doesn't provide Debian or Red Hat
packages, the downstream does that.  When Emacs is downstream, it
will be expected to do the work, if anybody does.

 > > So far they have not and it's not a priority to them.  Eli did a lot of
 > > work cleaning up the code and getting it to compile--it's thanks to him
 > > that Emacs has a recent GnuTLS DLL.
 > 
 > So, why should this fall on us?  I mean, is Emacs the only program
 > using gnutls?

Wrong question.  The question is does Emacs (which is a collective
work drawing on many packages not developed here) use GnuTLS?  If so,
is there an existing distribution of GnuTLS that "enough" users use so
that it's preferable to ask the users who don't have it to download it
themselves, rather than include it in the Emacs (or ELPA) distribution?

The debate here is about the value of "enough".  Ted wants much closer
to 100% than Eli and Juanma think necessary.

 > If so, why?  what do other programs use?

Most programs I know of use OpenSSL.  There are political problems,
and maybe license problems (the EAY clause) with Emacs doing that (but
see the list of OpenSSL users below).  From my MacPorts installation:

MacPorts 14:40$ port dependents gnutls
gnutls has no dependents.

(My build of the Emacs trunk depends on gnutls, but not the MacPorts
version I currently have installed.)

MacPorts 15:03$ port dependents openssl
cmake depends on openssl
curl depends on openssl
cyrus-sasl2 depends on openssl
git-core depends on openssl
gnome-vfs depends on openssl
kerberos5 depends on openssl
neon depends on openssl
openldap depends on openssl
openssh depends on openssl
python26 depends on openssl
python27 depends on openssl
python32 depends on openssl
python33 depends on openssl
qt4-mac depends on openssl
serf0 depends on openssl
serf1 depends on openssl

Note that these are only the installed packages (so it's biased to my
taste), and there are several cases of multiple versions (but the
ratio is nevertheless damning).  Note that even gnome-vfs depends on
OpenSSL.

 > If not, what do the other programs do about it?

Avoid it, apparently.

 > Ah, so the problem is not only for Windows but also for Mac OS X?

The problem exists for all OSes.  Eg, Debian stable is probably more
out of date than either of the above (until sometime in the next few
days if I'm reading the tea leaves right).

However, aggregating Mac and Windows here should be done with great
care (see below).

 > As a user, I wouldn't like it for a program such as Emacs to decide it
 > will take over responsibility for a generic library used by other
 > programs, so I find the idea of distributing it via GNU ELPA rather odd.

That's because you don't use Windows.  Windows users are used to that,
and in fact prefer it (if done right), because many programs have
problems with the "wrong" version of certain libraries, so they bundle
them.

Mac, however, is much closer to the *nix ideal of one instance per
package, so I suspect a lot of Mac users would prefer to use their
system version of gnutls, whereever it comes from (mine comes from
MacPorts).  But "DLL Hell" is a pain on many *nix systems as well (eg,
my Gentoo update is currently blocked because SBCL demands one version
of certain libraries, while Gentoo wants to install more recent ones).
It is also common in Python applications (MacPorts installs a separate
compilation of each library I install for all interpreter versions I
have -- I need 3 to support various applications, plus the most recent
release for development).

Heck, Emacs (until the advent of ELPA) was perhaps the premier example
of this behavior: distribute all the Lisp anyone could ever want, so
that the developers could have a free hand in refactoring.  XEmacs
proposed (on several occasions) that one of the existing systems
(XEmacs and the OSU repository are two I remember, the latter not
really being a package system but rather a classification system) but
were refused.  The reason given was that all Lisp was part of Emacs,
and Emacs could only afford to support one version of the language at
a time so a package system made no sense: it would constrain the
language development too much.

That said, indeed there are Mac users who expect full-blown
installers.  But I would expect them, by the same token, to mostly be
using Aquamacs.  In that case you can leave it up to the Aquamacs
maintainer(s), and the issue is restricted to Windows.