Re: Bits from dpkg developers - dpkg 1.16.1

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Ian Jackson wrote:
> > It was always completely wrong of dpkg-buildpackage to set these
> > variables.  Source packages are entitled to assume that strange
> > environment variables which cause their tools to do odd things will
> > not be set.
> 
> I'm willing to not worry about the likelihood that many packages added
> or updated over the past few years, while dpkg-buildpackage was forcing
> build flags, will not be built properly optimised now. That seems
> unlikely to completely break many of them, and as you say, forced build
> flags were always wrong, and we may just have to suck it up and deal
> with the breakage to get back to sanity.

Right.  (Also those forced build flags would sometimes cause the build
to break entirely.)

> My concern is that we now have a whole history of ill-considered changes
> to the build flags. To the point that it's possible to argue that every
> build flag change save one* has been ill-considered. So why are we
> continuing to add interfaces where the build flags are changed
> centrally/globally, with the same processes that have not worked before?

In one sense, yes, we are providing a way to set these flags locally.
But the new mechanism will make it much easier to locally override
such settings (where "locally" means either in the package, in the
build environment).

> The build flags interface either needs some sort of compatability
> versioning, or the default build flags need to be specified in policy,
> and only changed with the same care we take with other policy changes
> that can make massive numbers of packages instabuggy.

I agree that we need a good process for testing default build flags
changes before propagating them.  I'm not sure policy is the right
forum, but debian-devel is.  Perhaps the policy should be that we
don't change the default flags without consultation here ?

Ian.