On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote: > Raphael Hertzog <hertzog@debian.org> writes: > > On Wed, 10 Sep 2008, Bill Allombert wrote: > > >> 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. > > > > But more and more people want to be able to change distribution wide > > default: Emdebian wants to enable "nodocs" and "nocheck" by default, > > other want to be able to enable hardening options by default and I agree > > with them that official support for such a facility is desirable. > > So they should set DEB_BUILD_OPTIONS in the environment. That's what it's > for. I don't have any objections to that, or even to doing it via > dpkg-buildpackage. That is what DEB_VENDOR seeks to achieve - set it once and it sets the same options across all builds, in the environment. This is getting to be a long list of CC: - isn't it worth sending to debian-devel instead? Goswin von Brederlow and Simon Richter did a lot of work on this at Extremadura and they aren't on the current CC:. I'm losing track of all the bugs in the CC: and why they are listed. > My objection is specifically to having dpkg-buildpackage set a variety of > environment variables *by default*, and then telling package maintainers > that they should rely on those environment variables being set in the > default case. If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for Debian and will continue so. > That breaks the debian/rules interface and requires that > all package builds go through dpkg-buildpackage. Having dpkg-buildpackage > set environment variables in the non-default case like Emdebian is not a > problem, since for Emdebian builds (for example) Emdebian can decide that > using dpkg-buildpackage or setting the environment variables manually is > required. There is no existing precedent, and they can make that rule > from scratch. Exactly. > My concern is for the default build where there *is* an existing precedent > that debian/rules build should work sanely, not for support for special > cases like that where the existing debian/rules interface already doesn't > do the right thing without additional help. > > If you are going to go down this path of having dpkg-buildpackage set up > an environment that package maintainers should rely on, you or someone > else on the dpkg team needs to make a debian-devel-announce post making it > clear that debian/rules build is no longer a supported interface for > building packages and using dpkg-buildpackage is required for consistent > behavior. > > Right now, I don't think most Debian Developers have any idea what the > implications of these changes are. That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set or is set to Debian. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part