On Tue, Oct 25, 2022 at 5:09 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
So this change is talking about a new GCC landing in Fedora 40.
To avoid massive disruption to Fedora though, we need to be doing
work waaaaay earlier than the Fedora 40 dev cycle though.
Identifying all the places where autoconf tests quietly change
their result, and silently toggle on/off alternative code paths
is going to be a big job on its own.
Once identified there's the even more work to figure out the right
changes needed. I don't know how many packages rely on autoconf,
but the idea of carrying patches in Fedora and re-running autotools
to re-create configure, isn't that appealing on a large scale.
Obviously the preferred solution is to be able to report the problems
upstream, and get the fixes included in the next upstream release
and then rebase in Fedora. Even better is if a major information
campaign brings this change directly to the attention of upstreams
communities, bypassing the distros where there is an active upstream.
I'd be concerned about the timeframe for getting through this dance
for a non-negligible number of packages.
>
IOW, this change is talking about something in Fedora 40, but it
feels like the vast majority of work needs to take place in Fedora
38 and Fedora 39. Fedora 40 neeeds to be nothing more than a "flip
the switch" scenario, otherwise history suggests the change is likely
to end up getting punted to Fedora 41/42.
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?
I feel that this need to start on the prep work in F38/F39 is not
very obvious from the F40 change proposal text.
So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s)
to describe the prep work that needs to be done across packages in these
two releases as a matter of urgency, in order to make it possible to the
F40 change to actually happen ?
Concretely, as an upstream maintainer, what should they do to test
the behaviour of their code ? Is there more to it than just
setting CFLAGS="-std=gnu99", if they want to validate this in their
upstream CI ahead of GCC 14 arriving ?