[Pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[Helmut Grohne]

On Thu, Sep 18, 2014 at 12:09:03PM -0400, Daniel Kahn Gillmor wrote:
> On 09/16/2014 02:49 AM, Helmut Grohne wrote:
> > On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote:
> >> we would need to move /usr/include/gpg-error.h to
> >> /usr/include/$ARCH/gpg-error.h (since that file varies by architecture).
> 
> I've made this change with libgpg-error 1.16-1, which i just uploaded to
> unstable.

Thanks!

> What do you think of the approach i describe above (shipping
> gpg-error-config with a tuple prefix, and using /etc/alternatives for
> gpg-error-config)?

It's terrible (at least for now).  By making it an alternative you
effectively remove gpg-error-config from the API provided by the
libgpg-error-dev package.  If I install libgpg-error-dev for two
architectures and build a reverse dependency, dpkg-checkbuilddeps will
tell me that Build-Depends are satisfied.  However, if I choose the
wrong alternative my build will fail.  Since the behaviour of
gpg-error-config now depends on an administrator choice, packages that
Build-Depend on libgpg-error-dev can no longer expect gpg-error-config
to work.  At this point we'll have to teach all build-rdeps to use the
triplet prefixed version.

At least for now, this solution sounds terrible to me, because it may
cause breakage and when it does, it is subtle and hard to spot.

That said, I am still in favour of shipping TRIPLET-gpg-error-config now
and moving reverse dependencies to calling it by that name.  At a later
point, we may want to rebuild all reverse dependencies with
/usr/bin/gpg-error-config removed and if that succeeds revisit your
proposal.

Alternatively, stop caring about this bug for now, because those aspects
that make cross-building work reliably are implemented now. The package
that needs libgpg-error both for build and for host has yet to be found.

Helmut