Re: Environment variables, debian/rules and dpkg-buildpackage
Raphael Hertzog <hertzog@debian.org> writes:
> On Mon, 11 May 2009, Russ Allbery wrote:
>> 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.
Why would you want to disable all hardening instead of filtering out the
flag that breaks the package?
> 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.
Which again I agree with but it's orthogonal to what you're talking
about. You can do that either way.
> 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 Standards-Version.
In which case again you're not using Build-Options-Supported.
Besides, I'm skeptical that's the right way to handle that transition.
It seems to me like it would be a lot more effective to add a Lintian
test first, warn everyone, do a mass bug filing, and otherwise follow
the same practice we always use for global archive changes. That's the
procedure that we follow when we're trying to do something that changes
large numbers of packages. Basing it off Standards-Version to my mind
just creates FTBFS landmines in the archive that will be exploding for
years to come as people update old packages and don't think to add
build-arch. I suppose that has the advantage of spreading the pain out
across many years, but wouldn't it be better to get it over with?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: