On Tue, Oct 25, 2022 at 5:09 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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 ? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
