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? > But the last remaining piece of doing this work is to deal with > /usr/bin/gpg-error-config, which differs by architecture. > > The first recommendation here: > > https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages > > is to help upstream switch to pkg-config, which Werner has explicitly > stated he has no interest in doing, so that's out. > > All of the recommendations seem pretty problematic, actually, in terms > of forcing an archive transition -- we'd require our downstream > dependencies to change how they invoke gpg-error-config. > > One other approach, i suppose, is to modify gpg-error-config itself > somehow to be able to invoke it with a different triplet (but have it > default to something sane?) > > I'm really not sure what the best way to approach this is, but i'm open > to specific suggestions. Well put. This issue boils down to upstream providing an inexact API. It cannot be fixed without help from both upstream and library users. Let me explain why switching to pkg-config would magically solve this and draft an upstream-acceptable solution from there. 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. 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. 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. Helmut -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
