On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer <fweimer(a)redhat.com> wrote:
* Alexander Sosedkin:
> Since it's a build-time-only change,
> can it be rolled out under controlled pressure like this?
>
> 1. every package explicitly opts out (with some macro in specfile, IDK)
> 2. switch gets flipped, nothing changes
> 3. bugs get filed to drop that macro and opt into new behaviour
> 4. opting in gets resolved at a leisurely pace
> across as many releases as needed?
Sorry, what's the advantage of doing it this way?
Spreading out the porting effect =)
Maybe I'm scarred by my own unsuccessful attempt
to spread out SHA-1 switch flipping across releases,
but this sounds like a switch that'll need maintainers
to not just react, but also coordinate with upstreams,
and Fedora's tight cycle is uncomfortably tight.
We'd have to change all packages that have a C compiler
in their buildroots as part of the first step.
OK, maybe just the ones failing to build with C99.
Then we file thousands and thousands of bugs, and hope that
the maintainers take action? I'm not sure that's going to work for
those maintain dozens (hundreds?) of packages. It's also kind of
difficult for a Fedora developer to predict GCC 14 behavior in 2024
today.
Relying on individual developer action also means that we'd have to
teach many more people about C arcana and autoconf corner cases. I
don't think that's a good learning investment to be honest. Most of
this knowledge was already obsolete in 1999.
I don't really know how much time we have before GCC disabled legacy C89
extensions by default because some of them are incompatible with future
C language directions. I'm not convinced things will resolve themselves
over time. Obviously there's been some progress in the last 25 years
(not everyone uses GCC and Clang with their extensions to build upstream
software), but it's been really slow so far. (Back in 2019, I quickly
found a bunch of really core packages that needed fixes.) It's also not
clear to what degree the Macos efforts that Clemens mentioned have
reached upstreams. It doesn't seeem to have helped the Clang 15 release
much.
To me, all these things argue against spreading out the porting effort.
¯\_(ツ)_/¯
I wish we could do it this way, but it doesn't look like it's
a feasible
option.
One cycle or many, I wish you to find the best way to pull this off.