Hi!
On Sat, 2024-03-16 at 02:18:22 +0200, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.22.6
> Severity: serious
> X-Debbugs-Cc: Steve Langasek
> 3. Code that does still compile with -Werror=implicit-function-declaration
>but behaves differently, e.g. due to failing autoconf tests silently
>disabling features
> Debian has automation listing implicit-function-declaration warnings
> in all packages already running for several years:
> https://qa.debian.org/bls/bytag/W-implicit-declaration.html
> My main worry is point 3, issues like #1066394.
>
> #1066394 was found due to causing a FTBFS in a different package,
> but the more common case is likely that a program has some
> feature/plugin disabled and this won't be spotted until much later.
>
> "Much later" might be after the release of trixie a user upgrading
> to bookworm who uses this feature.
>
> Or it might result in a program silently using an insecure legacy codepath,
> e.g. after a test for getentropy() failed.
Not enabling this -Werror might imply ABI breakage for the time64
transition, which seems pretty terrible too. The way I see it, and
given the timing, effort and preparation necessary for this transition,
both options (enabling or not enabling the fatal warning) are potentially
bad in their own way.
But given that these are clearly bugs, that not enabling them can imply
ABI breakage, that if things go according to plan (AFAIK) this will be
made the default anyway with gcc-14, that we can track those down, and
people have already been doing that for the Modern-C effort, see:
https://fedoraproject.org/wiki/Changes/PortingToModernC
https://wiki.gentoo.org/wiki/Modern_C_porting
I think we might as well just cope with this anyway right away.
> A large part of the packages in unstable might not get recompiled
> between now and the release of trixie, creating the additional
> issue that any such problem might occur only after a security update
> or point release update if this is the next rebuild of the package
> in trixie.
AFAIUI (and I'd expect) the whole distribution needs to be rebuilt
anyway as part of the time64 transition, otherwise the 32-bit ports
that are affected by it, will not benefit from it. So I don't think
this should be a concern.
So I'm inclined to close this, and consider the current state, the
less bad one. :/
Thanks,
Guillem
