[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from dpkg developers - dpkg 1.16.1

Ian Jackson wrote:
> I'm one of the submitters of one of the bugs which requested this
> change.  This is a reversion of dpkg to a previous behaviour, and it
> /un/breaks packages.  Or at least I think it unbreaks much more than
> it breaks.
> 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.

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?

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.

see shy jo

* As the exception that proves the rule, there was a proper cost/benefit
  analysis of adding -Werror=format-security, concluding that the 5% or
  so of packages that it breaks are likely to have security holes that
  it will aid in fixing.

Attachment: signature.asc
Description: Digital signature

Reply to: