One example (of many): https://bugzilla.redhat.com/show_bug.cgi?id=2351130

CC: @besser82

Discussion on list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/R43VT2ZK2KAUXWLCL7ZADKMKCMYMRMVB/

(The cmake_minimum_version related failures have since been partially mitigated by setting CMAKE_POLICY_VERSION_MINIMUM to 3.5 as an environment variable. This means that packages that are otherwise compatible with 3.5+ but just never declared that in cmake_minimum_version will still build as a result. But that is just a workaround.)

It's not a proper solution because other environments that do not use the %cmake macro will still be affected and if a dependency was built successfully with this workaround, later on when the -devel package is consumed and it still has the cmake_minimum_version(VERSION 2.8) it will continue to fail.

In addition, the maintainers chose to remove a number of "non-standard" installation arguments from the %cmake macro.

I am in favor of reverting this and addressing it at a later point.

creation of a cmake3 compat package.

I guess this would be just a temporary package to mitigate the koschei failures? On second thought this might be a good choice. Just need to get a full set of failing packages

We have 2359 srpms in rawhide that BR:cmake. I don't think anyone has gathered the stats on how many of those would be affected, but even if it's a small percentage, we're going to have a huge number of FTBFS or mis-built packages. We need to make the upcoming changes widely known and give people time to prepare.

Proposal: We request that the update to cmake-4.0.0-rc and the dropping of the non-standard-install options are immediately reverted in rawhide. A Change Proposal should be filed for the update for F43.

--

I'll add it to today's FESCo meeting agenda, because it's affecting a lot of packages and maintainers. @lecris, @besser82 It would be great if you could join us at 17:00 UTC in https://matrix.to/#/#meeting:fedoraproject.org.

@yselkowitz is invited too, of course.

I have kicked-off 2 MPB:
- https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0-revert/builds/
This is an impact check for after reverting my commit to catch all remaining failures.
- https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/builds/
This is an impact check for all affected packages due to both my commit and cmake-policy issue.

+1 to revert - we were recently discussing requiring key toolchain packages to have impact analysis before major updates, and this sounds like one of those.

Can we do this in a way that avoids an Epoch bump? I'd really rather not have that if we don't need to. Even a 4.0.0~really3.31.6 temporary version would be better.

I'm +1 for revert and going through Change process.

Also I don't mind if we have to add an Epoch to the package ... assuming that that wouldn't cause broken dependencies, of course. Then Neal's suggestion would be better.

Also I don't mind if we have to add an Epoch to the package ... assuming that that wouldn't cause broken dependencies, of course. Then Neal's suggestion would be better.

I'd rather not have people's versioned cmake BRs break.

We could also just untag all the cmake v4 builds from rawhide and wait for a Change document before resuming.

I was told we cannot untag the builds after the compose has run?

We've done it before in extreme circumstances, and I think this counts as one of those.

We can't do it for stuff shipped in frozen/GA repos, though.

+1 to reverting.

Just untagging them doesn't really help since anyone that has updated in the meantime still needs a proper upgrade path.

I'm really not fond of faking up the version vs. using an epoch here, but given the way many packages have handled their dependencies, that does seem like the most compatible solution for now. I guess I'll hold my nose and live with it.

People should be using distro-sync on rawhide. That's the only reasonably supportable upgrade command.

Started the draft for the change proposal https://fedoraproject.org/wiki/Changes/CMake4.0

We discussed this during the FESCO meeting today:
AGREED: We ask releng to untag cmake-4.0.x builds from rawhide and the maintainers to revert the update in dist-git for now. A Change proposal should be then filed and discussed to figure out how to do the transition in a smoother way.

https://pagure.io/releng/issue/12639 is the ticket for untagging, and it's been resolved already.

776/2359 packages affected: https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/builds/

This is without forcing CMAKE_MINIMUM_REQUIRED to see which ones are trivial to update

776/2359 packages affected: https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/builds/

This is without forcing CMAKE_MINIMUM_REQUIRED to see which ones are trivial to update

I have prepared the change proposals, and could use some feedback on them:
- CMake 4.0: https://fedoraproject.org/wiki/Changes/CMake4.0
- Drop *_INSTALL_DIRS: https://fedoraproject.org/wiki/Changes/CMake_drop_install_vars

I am not able to get in touch with @besser82 though.

1. Drop *_INSTALL_DIRS

Summary
Drop variables that are not standardized by CMake *_INSTALL_DIR, SHARE_INSTALL_PREFIX and LIB_SUFFIX.

The summary should be a statement of what changes and where. And also please assume that the reader doesn't have any context. The first sentence of "Detailed description" is better, it could serve as the first draft of "Summary". But also, a few words to give a hint what those variables are would make this much easier to interpret for somebody who hasn't followed the discussion.

Also, if possible, do not use shorthands like *_INSTALL in the explanation. People will want to search for specific variables that stopped working for them, and that's much easier when then they are explicitly enumerated.

Contingency mechanism: The corresponding cmake PR will not be merged until the affected packages are patched

The "contingency mechanism" is a plan of action to take if the change turns out to be incomplete or problematic, after the implementation has started. For changes like this, the mechanism would generally be "revert the changes to the %cmake macros" and also possibly "revert changes to specific packages".

The Change page looks reasonable. I like that you said "The corresponding cmake PR will not be merged until the affected packages are patched", though this should move to Description. If we do it this way, I can support the change. I wouldn't want for us to plan to do such a complicated change for F43 (or for some other fixed deadline).

1. CMake4.0

Again, the Summary is on the brief side. Maybe something like this:

CMake is updated to version 4.0. This version breaks compatibility with projects that specify cmake_minimum_required to a value smaller than 3.5. Projects will need to ensure ….

Please remember that people reading this text are often not CMake experts, so jumping right into deep details should be avoided.

Provides: cmake3 will continue to be included. Provides: cmake4 is NOT included.

The verb "included" is not clear in this context.

Some sentences are missing punctuation.

Contingency mechanism

Same issue as in the other proposal.

Thanks for the suggestions. Made some changes, wdyt now?

Should I move the changes to ChangeReadyForWrangler? And would I need a Change Shepherd, or would working with PRs be sufficient? I have gathered the list of affected packages in a table below. It includes the results of this change which does have a degree of overlap.

Should I move the changes to ChangeReadyForWrangler?

Yes, please.

And would I need a Change Shepherd, or would working with PRs be sufficient?

I don't think this is what a Change Shepherd is for, but I've never met one since I was on FESCo, so I might be wrong :) But it might be good to have a Change co-owner who is in the provenpackager group, to merge PRs that sit unattended for too long.