* 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? We'd have to change all packages that have a C compiler in their buildroots as part of the first step. 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. Thanks, Florian _______________________________________________ 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
