[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