Re: Environment variables, debian/rules and dpkg-buildpackage
Raphael Hertzog <firstname.lastname@example.org> writes:
> On Mon, 11 May 2009, Russ Allbery wrote:
>> I still think Build-Options-Supported is fundamentally the wrong way
>> to implement that. You have to modify every package to add it
>> anyway, in which case you can just as easily support it in the
>> package's debian/rules the way that we already support various other
>> DEB_BUILD_OPTIONS settings.
> Except that with the centralized approach we can have an opt-out
> policy after some time (ie use hardening options by default except for
> packages that have set no-hardening).
That seems orthogonal. Either way, you have to get most package
maintainers to modify their packages and test to be sure that you can
change the default build flags. Either way, the results of that change
will produce artifacts that you can look for to see how many packages
are currently building with the new flags. Either way, there is a way
for maintainers to opt out of default flags.
I understand conceptually how Build-Options-Supported could be useful,
but I've yet to see a specific application for it that doesn't seem like
it would be better done some other way. For example, saying that you
support parallel builds there seems inferior to just enabling parallel
builds if the DEB_BUILD_OPTIONS flag is set and you support it. Opting
in to specific features similarly makes more sense as DEB_BUILD_OPTIONS
to me. Opting out of default flags can be done with make's filter
support. build-arch/build-indep should just be *done* rather than
asking packages to say whether they support it, IMO.
> My interest in centralizing those is simplifying any transition in
> default flags that Debian would want to do. User customization is nice
> but it's not what motivates me to push this forward.
Sure, that's the point of the whole discussion: how best to do that
across the archive and whether we should break debian/rules build in
order to do so. I think there's general agreement on the goal.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>