On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote: > Raphael Hertzog <[EMAIL PROTECTED]> writes: > > > I think we're already on that path for quite some time. If your package > > uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting > > them for you (with dpkg-architecture). > > I most certainly do not rely on dpkg-buildpackage setting anything. I > call dpkg-architecture directly, which is also what's in our best practice > documents. > > DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) > DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) > > I would consider packages that didn't do that and just assumed that those > variables were already set to be buggy. > > > The same is expected with default values of builder/linker flags now > > that dpkg-buildpackage provides reasonable defaults. > > Yeah, that bothered me too. I made a perhaps poor tactical decision to > not fight about it since it seemed that it had a lot of momentum and I > couldn't think of specific problems other than the one that we ran into. > But this is going beyond setting some defaults that are already set in > nearly all of our packages. > > > So yes, I'm somehow building on this model where dpkg-buildpackage can > > simplify the work of packager by providing some distribution-wide > > reasonable defaults. > > > > People have noticed that and already requested that we can call arbitrary > > targets of debian/rules with all the proper initialization done precisely > > for test purpose during packaging work (see #477916). > > I must say, I really do not like this direction. debhelper and cdbs and > similar sytsems are the places to provide this help where people want to > use it, in my opinion. We have a lot of past experience with that and we > have the compatibility level to handle smoothing transitions. (And to > provide a way for people to never transition, I admit, and I see where > that's the problem that you're solving, but I prefer that problem to the > problems introduced by the instability of having the package build > infrastructure change the input to the builds without coordination with > the package.)
I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
