Re: GnuTLS for W32

[Ted Zlatanov]

On Mon, 02 Jan 2012 19:39:12 +0200 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Mon, 02 Jan 2012 11:16:34 -0500
>> 
>> In any case, it's better to have the *ability* to issue updates than
>> not to.  In that context, it seems more sensible to package GnuTLS
>> support as an ELPA package so it can be upgraded without upgrading
>> Emacs as a whole.

EZ> It makes sense, but how is ELPA easier than any other download
EZ> address?  All that's needed is to download a single zip archive and
EZ> unzip it.  Why does it matter if it comes from ELPA or from
EZ> elsewhere?

ELPA updates can be done entirely from within Emacs.  Downloading and
unzipping a file is a nuisance.  Imagine if you asked GNU/Linux users to
do the same.  "But they have package managers..."  Exactly!  And so does
Emacs, now that package.el is here!  So let's use packages for
non-trivial work.

>> So perhaps we just need a versioned "gnutls-w32" ELPA package to
>> DTRT.  W32 users can choose to install it or it can be installed by
>> default, whichever we or the distribution decides.

EZ> The alternatives are:

EZ>  . have GnuTLS as part of the binary zip

EZ>  . have GnuTLS as a separate zip alongside the binary zip (we do this
EZ>    for libxpm)

EZ>  . have GnuTLS available for download from some other address

I think the right solution is to ask the user "you don't have the GnuTLS
package for W32, do you want to get it?" and then do it through ELPA,
when they try to use HTTPS for instance.  The same, actually, should be
done with libxpm and any other add-on DLLs.  So this work could become
much more useful than just for GnuTLS.

Can Emacs modify the DLL search path on W32 so it can install some DLL
from ELPA and then activate it dynamically?  Or does it require a
restart and modifying the global PATH?  Either way, can the process be
automated?

On Mon, 2 Jan 2012 18:31:24 +0100 Juanma Barranquero <address@hidden> wrote: 

JB> 2012/1/2 Ted Zlatanov <address@hidden>:

>> I stated I would do that monitoring.  In any case, it's better to have
>> the *ability* to issue updates than not to.

JB> We already have the ability to issue updates, because any update is
JB> just getting the info to the user (whether they download a binary
JB> tarball from us or somewhere else, the only real trouble is getting
JB> the user to know that there's a security issue to be fixed in the
JB> first place). In that regard, announcing a new release or announcing
JB> that the user should upgrade their GnuTLS binary is largely
JB> irrelevant.

ELPA, however, can show the user all the packages that need to be
updated in one place, so they don't have to check for GnuTLS updates on
W32 specifically.  It should be set up to check on startup, IMHO.
That's a win (heh heh) for everyone, and fits with what users expect
nowadays, compared with other extensible software like Firefox and
Chrome.

JB> But anyway, the issue is not just monitoring. Someone has to build
JB> updated binary GnuTLS packages for Windows. That Eli just did it does
JB> not mean we can burden him with the task forever.

We can automate that.  Eli and Nicos have done the hard part, I think.
Ditto for an ELPA package, if we can do it once it can be automated.

Ted