Re: GnuTLS for W32

[Eli Zaretskii]

> From: Ted Zlatanov <address@hidden>
> Date: Mon, 02 Jan 2012 17:35:21 -0500
> 
> 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.

See below: currently, using this for anything not Lisp-based, like
installing a new dynamic library, is a pipe dream.  (Actually, even
downloading a new version of a Lisp library into a running session has
its problems, as discussed here recently; but I digress.)

> 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!

And I thought only Windows users were spoiled enough to demand
one-click installations.  "Downloading and unzipping is a
nuisance"... sheesh.

> 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?

We currently lack infrastructure to replace a DLL that is already used
by a running Emacs process.  The code that loads a DLL and initializes
the function pointers used to access its APIs assumes this will be
done only once in a given session, so currently we do need a restart.

To be able to replace a DLL without restarting Emacs, we would need to
add code to free and unload a used DLL from the Emacs process, and
then load the new one.  This might be complicate if there are data
structures lying around that use the DLL facilities, like an existing
connection using GnuTLS or an image displayed using an image DLL.  We
will need to shut down the relevant Emacs features before replacing
the DLL.

There will also be complications with this if another Emacs process
runs the same binary and uses the same DLL, because I don't think you
can overwrite the DLL from under the feet of that other process.

If you are thinking about a limited goal of installing for the first
time a DLL that does not yet exist and is not loaded into Emacs, then
it can be done, although some code will need to be written for that as
well, and I'm not sure package.el is designed to handle such
"packages".  Moreover, I'm not sure such a limited goal would be in
the spirit of package managing, since upgrading an installed package
is an important part of that, perhaps more important than the initial
installation.

> 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.

Who exactly are "we" in this sentence?

> Eli and Nicos have done the hard part, I think.

I did nothing of the kind.  I just configured and built the stock
distribution, and fought whatever problems I found that prevented the
build and the test suite to run to completion.  The record of that
fight includes 18 "issues" which I will be reporting to GnuTLS
developers soon; until those are resolved, the build I did is anything
but an automatic thing.  And I don't see how anyone else's build can
be fully automated, unless the "issues" I bumped into are due to my
own misunderstandings.

In any case, my experience indicates that having a steady feed of
regular updates of Windows builds of any non-trivial package can never
be based on a single individual, no matter if his/her name is Eli,
Nicos, or something else.  People invest in this some time for as long
as they have it or are interested, and then go away to pursue other
interests or go on with their lives.  You cannot build a reliable
infrastructure on something that is not part of your project.

Bottom line, I feel that letting users download and unzip DLLs is by
far more practical for this purpose than what you suggest.  It also
has the advantage of already working.