[pkg-gnupg-maint] A merge request to libgpg-error

NIIBE Yutaka gniibe at fsij.org
Tue Aug 1 01:37:47 BST 2023


Hello, again,

I decline the merge request of mine.  It was good for me to share the
issue with Debian, before bringing problems to users.  Thank you.

I see that how the change brings a risk into Debian, with less benefit.

For now, the difference doesn't matter a lot.  Benefit would be only for
the (small) cleanness of gpgv for Windows 64-bit in Debian.  The risk is
for the entire build process.

Potentially, when some developers start their development with
libgpg-error-mingw-w64-dev of Debian package, for 64-bit executables,
they may encounter the compatibility problem (against other build).  But
this is a kind of rare case, I suppose.

We still have some time until the official support of Windows 64-bit
version.  We could find some better way to achieve different DLL names
(than dynamic patching by configure).  Or, removal of the local
modification of libtool could be also a technical option, in my opinion,
at the start of the official support.

Well, I am going to find a way to modify my environment of Windows
emulation, so that I can work with the same name libgpg-error.


>From here, it's something TL;DR but my execuse.

Andreas Metzler <ametzler at bebt.de> wrote:
> I think this is an somehow intentional difference from upstream.

In that case, my merge request was a bit violent.  Sorry, I didn't
consider this possibility enough.

My actions were like:

(1) I noticed same DLL filename in Debian packaging (32-bit and 64-bit),
    with surprise.

(2) I felt it should be fixed sooner (before actual official 64-bit
    support in upstream GnuPG).

(3) I found a solution of mine which works somehow, although it's
    fragile and far from perfect.

(4) Pushed the change in upstream libgpg-error, the development version,
    so that it won't be hidden.

(5) Write the merge request, by backporting from the development
    version.
-- 



More information about the pkg-gnupg-maint mailing list