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

[NIIBE Yutaka]

Andreas Metzler <ametzler at bebt.de> wrote:
> Change #1 makes ./configure patch libtool for host x86_64-*mingw32* to
> change the dll name from libgpg-error-0.dll to libgpg-error6-0.dll.

Yes.  Debian packaging has been ignoring this local modification of
upstream GnuPG.  I thought that it is unintended in Debian packaging.
But I may be wrong.

By ignoring this local modification of GnuPG in Debian, it results
difference between Debian build and build for x86_64-*mingw32* target by
other environments.  If it is unintended, it simply complicates things
unnecessarily.

So far, it was not a major problem, since x86_64-*mingw32* was not
officially supported by the GnuPG team.

Nevertheless, although it's not officially supported, there are some
users, who build for x86_64-*mingw32* host (like Debian does).

Currently, in the upstream of GnuPG, I'm working for the official
support of x86_64-*mingw32*: https://dev.gnupg.org/T6508

Then, I realized that Debian packaging has this issue.

> * I do not get the reason for this (I understand the rationale given
>   simply as "upstream does this, too").

There are some technical reasons to have distinct namespaces for 32-bit
and 64-bit, resulting different soname (for 32-bit version and 64-bit
version) of a given library.  It allows having a library for 32-bit and
for 64-bit within the same PATH or even in the same directory on a
single machine.  For me, it simplifies my development/testing
environment for Windows emulation (by a single environment both for
32-bit and 64-bit).

It's also by historical reason.  It's there for a decade.

I think it makes sense to value this local modification of GnuPG to
minimize surprise.  Please note that it was introduced by the commit:

	ca46b9a7bccb2eab085fc45722ffca1210f48223

> * It seems to be the wrong place to do this, this should happen in libtool
>   upstream.

For libtool upstream... yes, it would be good to consider this use case
of GnuPG (need of different soname).  It makes much sense to introduce
the support of specifying different soname by configure for different
host.

Well, with the form of the local change like ca46b9a7b, it's too much
for libtool upstream; If libtool upstream will intoduce such a change at
this stage, it will give too many surprises for x86_64-*mingw32* host
for *all* libraries.  It will give a little technical benefit, but it
will result more of suprises and more of problems.

> * It tightly couples buildability of the libgpg-error Debian package
>   with a specific libtool version.

I agree that it is not best to keep the local modification by the form
of patch against generated libtool;  Use of a patch here would be too
fragile.

When/if libtool upstream will have a feature to specify different
soname, we will be able to use the feature.  That will be clean and
stable solution.
--