XPost: linux.debian.bugs.dist
From:
[email protected]
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 <[email protected]>
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)