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). > > This move has benefits on its own. See > https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html > section 3.4. Can you implement it even if it does not solve this bug on > its own?
I've made this change with libgpg-error 1.16-1, which i just uploaded to unstable. > Standard autotools nowadays check whether host architecture differs from > build architecture and if that is the case, prefer build tools that are > prefixed with the gnu triplet of the host architecture. This mechanism > is well tested for pkg-config and works. In particular, the autotools > come with relevant macro files that do this for pkg-config, so library > users hardly get this wrong. In contrast, guile-config (another problem > of this kind) is always executed without that prefix and causes the very > same problem as does gpg-error-config. > > What does this mean for libgpg-error? > > First and foremost, both libgpg-erorr upstream and Debian should start > providing $PREFIX/bin/$HOST_TRIPLET-gpg-error-config as a symbolic link > to gpg-error-config. Once this is in place, we need to approach > library users to prefer this way of calling gpg-error-config. A good > citizen in this respect is libgcrypt20. Quoting from its cross build > log: > > | checking for x86_64-linux-gnux32-gpg-error-config... no > | checking for gpg-error-config... /usr/bin/gpg-error-config > > Once all library users are switched, the problem is solved from an > upstream POV. Hm, this is interesting. What if we actually shipped gpg-error-config as /usr/bin/$HOST_TRIPLET-gpg-error-config and made /usr/bin/gpg-error-config the symlink via the /etc/alternatives mechanism? This might let us mark gpg-error-config M-A:same, while still building cleanly by default for native builds and cross-builds for well-behaved dependencies. That means that only cross-building for poorly-behaved dependencies would be adversely affected, which seems like a much more narrow scope. > For Debian there still is a problem, because native builds still need > the script without architecture prefix. We need to deprecate using build > tools without architecture prefix and entirely move away from that. sure, but that's only critically relevant for cross-building of debian core, right? > So while this bug certainly cannot be fixed soonish, it still shows a > number of sub-issues that can be solved today. guile is in the very same > position and will not mark its -dev package M-A:same today, but guile > chose to move to pkg-config and will be able once all guile-config users > have been killed. Alas, i'm pretty sure that gpg-error upstream won't move to pkg-config (see the thread starting at [0] for example). 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)? --dkg [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html
signature.asc
Description: OpenPGP digital signature