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

Re: DEB_BUILD_OPTIONS=nowerror



Am 2023-02-28 01:39, schrieb Steve Langasek:
[some precursor

I can see that for bootstrapping a new architecture, it will sometimes be useful to use a toolchain newer than the one that is currently default in Debian, and as a result it is useful to also be able to bypass new stricter -Werror behavior from gcc upstream that breaks compatibility with existing
code.

I agree, this is one use case.

It isn't clear to me from the discussion history that this is the actual use case at issue. But supposing it is, that's one use case; and it's a use case that can be addressed without having to make any per-package changes
and without having to make any changes to dpkg-buildflags interfaces by
exporting

  DEB_CFLAGS_APPEND=-Wno-error
  DEB_CXXFLAGS_APPEND=-Wno-error

as part of the bootstrap build environment, for all packages.

Now, if all packages would just use the flags from dpkg-buildflags as is, or as the final part of CFLAGS/CXXFLAGS, that would be nice. However, IME, that is not always the case and some maintainers append -Werror in particular.

Of course, dpkg-buildflags also exports flags for other languages than C and C++ (and should do), so if you want to have full package coverage you would want your set of _APPEND variables to match the set of per-language flags that dpkg-buildflags already handles. Having to export 7 variables instead of 1 is annoying. But it also doesn't require reaching consensus on a new interface in dpkg. And I remain unconvinced that the particular proposed
interface is the right way around for Debian at large.

Following this discussion, I fear we might not reach consensus. But my ideal
(strong) suggestion to package maintainers would be:

1) Don't use -Werror (or equivalent for your packages language) during normal
builds (i.e. on buildd)

2) Do use -Werror via some mechanism (DEB_CFLAGS_APPEND)? during CI builds

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 since
your package was last built.

Derived distros: I see this quite regularly at Google - packages not rebuilt in Debian for months, now fail to build with newer gcc. While we use testing as our base (so usually not *too* far off from unstable), we do rebuild packages in testing more often than Debian would. Not strictly necessary in most cases, but most of the time, if package bar build-depends on libfoo-dev and that gets
an update, bar will usually be rebuilt (not always, but whatever).

Porting (as mentioned by Steve and others) - Porting to other architectures
often requires a different (newer) compiler version, which might lead to
failures with -Werror.

Cheers,
Sven


Reply to: