On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer <fweimer@xxxxxxxxxx> 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. _______________________________________________ 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
