Russ Allbery <[EMAIL PROTECTED]> writes: > Raphael Hertzog <[EMAIL PROTECTED]> 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.
Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. > 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. 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. Then you have one interface for Debian and one interface for every other vendor including ubuntu (or option 2 above). > 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. Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. > Right now, I don't think most Debian Developers have any idea what the > implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. MfG Goswin PS: with dpkg-buildpackage setting env vars like it does now you already have a verry confusing situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]