Am 2023-02-28 01:39, schrieb Steve Langasek:
I can see that for bootstrapping a new architecture, it will sometimes
useful to use a toolchain newer than the one that is currently default
Debian, and as a result it is useful to also be able to bypass new
-Werror behavior from gcc upstream that breaks compatibility with
I agree, this is one use case.
It isn't clear to me from the discussion history that this is the
case at issue. But supposing it is, that's one use case; and it's a
case that can be addressed without having to make any per-package
and without having to make any changes to dpkg-buildflags interfaces by
as part of the bootstrap build environment, for all packages.
Now, if all packages would just use the flags from dpkg-buildflags as
or as the final part of CFLAGS/CXXFLAGS, that would be nice. However,
that is not always the case and some maintainers append -Werror in
Of course, dpkg-buildflags also exports flags for other languages than
C++ (and should do), so if you want to have full package coverage you
want your set of _APPEND variables to match the set of per-language
that dpkg-buildflags already handles. Having to export 7 variables
of 1 is annoying. But it also doesn't require reaching consensus on a
interface in dpkg. And I remain unconvinced that the particular
interface is the right way around for Debian at large.
Following this discussion, I fear we might not reach consensus. But my
(strong) suggestion to package maintainers would be:
1) Don't use -Werror (or equivalent for your packages language) during
builds (i.e. on buildd)
2) Do use -Werror via some mechanism (DEB_CFLAGS_APPEND)? during CI
3) Actually utilize CI builds to detect any breakages early.
(1) helps in multiple cases, all of which are rebuilds of some sort.
Security: Minimize the patch to the package if the compiler was updated
your package was last built.
Derived distros: I see this quite regularly at Google - packages not
in Debian for months, now fail to build with newer gcc. While we use
as our base (so usually not *too* far off from unstable), we do rebuild
in testing more often than Debian would. Not strictly necessary in most
but most of the time, if package bar build-depends on libfoo-dev and
an update, bar will usually be rebuilt (not always, but whatever).
Porting (as mentioned by Steve and others) - Porting to other
often requires a different (newer) compiler version, which might lead to
failures with -Werror.