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 <vor...@debian.org>
> 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
