Re: Environment variables, debian/rules and dpkg-buildpackage
On Mon, 11 May 2009, Russ Allbery wrote:
> Raphael Hertzog <email@example.com> 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.
The fact that we can filter out some default flags doesn't make it
a better approach IMO. If you just want to disable hardening for your
package, it would be a pain to have to filter out a possibly evolving
list of default flags.
And yes, it's best when all package maitainers test their package
for the change, but quite a few are not as pro-active and you should not
assume that we will modify all packages. To complete any migration, we
must have the possibility to just do the change and manually fix up
packages where nothing has been stated.
(The approach might vary depending on the risks, etc but you get the idea)
> support. build-arch/build-indep should just be *done* rather than
> asking packages to say whether they support it, IMO.
Which means that policy must state "MUST" for those targets to exist.
In which case the Build-Options-Supported is implicit and derived from the
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :