Re: Environment variables, debian/rules and dpkg-buildpackage
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
> > 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
(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.
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :