Raphael Hertzog <hert...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
