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.
signature.asc
Description: Digital signature
