Re: Bits from dpkg developers - dpkg 1.16.1
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
> 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 ?