I observe a pattern repeated at least twice and probably more often in
* A package adds -Werror to the build. When a new toolchain version is
uploaded, it triggers a new warning and that makes the package FTBFS.
* A package runs shellcheck during build. When a new shellcheck is
uploaded, it triggers a new warning and makes the package FTBFS.
In general, the vast majority of packages does not use -Werror (except
specifically, e.g. via dpkg-buildflags) or shellcheck during build, but
employs such techniques during e.g. salsa-ci and that seems generally
preferred. However, some packages do still use this pattern.
* glibc adds -Werror
* nss adds -Werror
When building affected packages with more recent toolchains, such build
failures are annoying. In a bootstrap setting, they hide later problems.
For that reason, I would like to have a standard way to opt out of such
failures. I understand that some of the warnings may be pointing at real
bugs and that ignoring them certainly is a compromise. I also understand
that packages may fail to build for other reasons with new toolchains
(e.g. missing #includes). However, -Werror has proven to be quite
repetitive and seems worthwhile to address to me.
As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
the original observation, but meant to also match other checkers such as
shellcheck. The general idea should be that a warning should that can be
non-fatal should be non-fatal if possible.
Does this proposal make sense? Is there sufficient use case to support
it as a generic distribution feature (for a niche number of packages)?
>From a process point of view, I think this mail serves as a possible
standardization point. Packages can add support for this and the
responsibility for providing patches for this generally resides with
those interested in having it (i.e. me sending patches). Once we have
some adoption of this, we can add it to Debian policy.
So let me know if you think this is a bad idea.