Hi! On Tue, 2011-02-01 at 11:46:39 -0600, Jonathan Nieder wrote: > Colin Watson wrote: > > --- a/debian/rules > > +++ b/debian/rules > > @@ -80,6 +80,13 @@ install: check > > > > cd build-tree && $(MAKE) DESTDIR="$(CURDIR)/debian/tmp" install > > > > +ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes)) > > + # Ubuntu's "i386" architecture is built for i686 (the Debian default > > + # is i486). > > + sed -ri 's/^(i386[[:space:]]+)[^[:space:]]+/\1i686/' \ > > + $(CURDIR)/debian/tmp/usr/share/dpkg/cputable > > +endif > > +
I've pushed this to master, although I'm not entirely happy having this there (as hinted on the commit msg), it seems better to me than having diverging downstreams, if that can be helped. > All current uses of "$(shell" come after a "?=", which is presumably > good for bootstrapping a dpkg-less platform. In this case, it's > harmless --- if dpkg-vendor is missing, the only bad effect would be a > "command not found". Not really, bootstrapping should be possible from the pure upstream part (although there's some pending issues there), but the Debian packaging part relies on debhelper and dpkg itself, at which point you might as well have those installed in the system already (instead of say the build trees or a local directory). > Maybe we can keep debian/rules clean by making this hack available to > other distros, too. :) Would something along these lines make sense? > I'm not sure --- I was considering using a ./configure flag that can > be overridden in the Makefile but then the patch seemed to be growing > too much... Well it does not seem much cleaner than what Colin provided TBH :), yes the replacing logic is hidden but still there's the i386 and Ubuntu special cases there. At least Colin's changes are “contained”. So the other solutions/options I can come up with right now are: * Having different files per diverging downstream (as in cputable.ubuntu or similar), but this incurs a higher maintenance cost, which I'd rather avoid. * Adding a new vendor hook which can modify specific arch values at run-time. Although probably cleaner, it has the potential but improvable problem of unknown software using directly the tables instead of Dpkg::Arch or dpkg-architecture, and the confusion with unmatched file and output. But probably what we should move to in the future regardless, if nothing better comes up. thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
