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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
