Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote:
> Russ Allbery <email@example.com> writes:
> > Raphael Hertzog <firstname.lastname@example.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.
> 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
> 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.
2) is the right way to proceed for _Debian_. People in a hurry can use 1,
but not us.
2) imply that packages will not have DEB_VENDOR support unless some
check they support it.
> > 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.
Precisely, debuild does not use dpkg-buildpackage, but call debian/rules