Hi, I observe a pattern repeated at least twice and probably more often in packages.
* 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. Examples: * 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. Helmut