Looking for GnuPG-compatible library for server application

[Werner Koch]

On Sat, 20 Oct 2012 01:54, rjh at sixdemonbag.org said:

> I feel like I'm missing something important here: why would we need to
> do that at all?  What's wrong with providing the DLLs, the necessary

The gpg4win installation directory is populated with huge number of DLLs
and EXEs which should not be available in the PATH.  For EXEs we might
have only name conflicts but for DLLs it will be worse: Some of the
software in Gpg4win uses a lot of DLLS without proper versioning.  For
example if you install a second KDE based project, it might pick up a
wrong version of a DLL (i.e. from gpg4win, while it expected it from
somewhere else) and you run in all kind of subtle or severe error.

That is actually a real world experience (e.g. Kolab for Windows).  Once
there used to be the idea of a package manager for Windows, but the
different groups were not able to agree on a common solution.  The right
thing to do would be to use MSI, which is the package manager for
Windows.  However, we can't yet cross-build MSI and maintaining MSI
is a lot of work for us, given that we all rely on each other but have
no central control instance.

Thus I consider it better to publish (put into a PATH directory) only
those DLLs and headers with proper versioning.  And a few well known
binaries.

I guess that hardlinks will be the say to go.  The only open question is
how we can do it if a DLL is currently in use.  NSIS has some support
for overwriting, but I have not checked how this can be done if we use
CreateHardLink.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.