On Tue, 12 May 2009, Russ Allbery wrote: > > 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?
Because no-one has identified the precise flag that breaks the package? Or because you really want no hardening at all because you don't want to have to deal with subtle breakages caused by a supplementary hardening flags added later? I know that we always have many different opinions when it comes to implement some new stuff and I'd rather have some supplementary flexibility that is not needed rather than finding atferwards that we need more of it because when it concerns the whole archive, it's painful. > > 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. We suppose all packages already have the right include that imports the default cflags. So now, you decide it's time to use hardened flags by default so you just change the default flags. Is that right? How did we enable hardening flags on individual package before (in your scenario)? (Do we have a copy of all hardened flags in each package? if not where do they come from since the default flags don't contain them?) What were maintainers supposed to do in advance to disable some hardening flags that break their packages given that they don't even know for sure what the default flags will look like. Having stuff in place and just switching a test looks more predictable than not having it and simply relying on some d-d-a mail stating: in X months the default flags will be Y, try it out and make sure your package don't break when we do it. (But maybe I guessed this all wrong and you had something else in mind) > 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? Not sure at all. In part because only a small percentage of the packages would benefit from it (those that build arch: all and arch: any and where the work to compile doc for the arch: all is expensive). So targetting a MUST in policy is overkill in my opinion. Maybe the right thing to do is to make it mandatory only for packages that have both arch-indep and arch-specific binary packages. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
