Hide Forgot
Description of problem: There is a cmake3 package in Fedora EPEL for 3.17.x which will be unusable due the provides in the RHEL cmake package: # dnf repoquery --provides cmake Last metadata expiration check: 0:13:16 ago on Sun 03 May 2020 07:25:33 AM CDT. bundled(kwsys) bundled(md5-deutsch) cmake = 3.11.4-3.el8 cmake(x86-64) = 3.11.4-3.el8 cmake3 = 3.11.4-3.el8 # dnf repoquery --whatprovides cmake3 Last metadata expiration check: 0:17:30 ago on Sun 03 May 2020 07:25:33 AM CDT. cmake-0:3.11.4-3.el8.x86_64 Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /usr/bin/ccmake3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64 file /usr/bin/cmake3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64 file /usr/bin/cpack3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64 file /usr/bin/ctest3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64 How reproducible: Always Steps to Reproduce: 1. Manually install the cmake3 package from EPEL testing into mock 2. Try to build a package which has a BR: cmake 3 3. Mock still tries to install the CentOS cmake package even though the cmake3 package is already installed. Actual results: The cmake package prevents cmake3 from EPEL from being installed.
I believe this is a leftover from EL 7 where the base cmake package was version 2.
> I believe this is a leftover from EL 7 where the base cmake package was version 2. The most recent version of CMake in Fedora also packages the cmake3 command. I believe this is left in for compatiblity reasons.
Because the version in RHEL is 3.11 and the minimum for the program I'm building is 3.12 and the cmake3 package provides the current version 3.17.
(In reply to Alexander Korsunsky from comment #2) > > I believe this is a leftover from EL 7 where the base cmake package was version 2. > > The most recent version of CMake in Fedora also packages the cmake3 command. > I believe this is left in for compatiblity reasons. Fedora has been on "3" so long I think that's silly at this point as any breakage is trivial to fix.
Why does EPEL have a cmake3 package? Isn't the base version already cmake-3.x ?
(In reply to Tom Stellard from comment #5) > Why does EPEL have a cmake3 package? Isn't the base version already > cmake-3.x ? Please see comment 3.
The plan for providing new cmake versions in RHEL8 is to use modules. I would recommend this for EPEL as well if possible. Otherwise, I think it would make sense to rename the cmake3 package in EPEL to cmake3.17. Having a cmake3 package when the base version is already 3.x seems confusing to me.
Which means you would have to rename the package on ever minor update (3.18..). As far as package name maybe "cmake-latest" would be ok, but what would you name the binaries?
Or the package name would be "cmake", the binary would be called "cmake" and the module stream would be called "el8-cmake-latest". That way, there's no need to have versioned package names or conflicts and less confusion, because you could just update the base cmake package to the newer version when you activate the module.
Are EPEL modules possible yet?
There is a Modular EPEL repository already: https://bodhi.fedoraproject.org/releases/EPEL-8M
How are used Modular EPEL repository?
(In reply to Antonio T. (sagitter) from comment #12) > How are used Modular EPEL repository? Very good question, how in deed? I have looked for documentation, but so far I only found the relevant documentation for Fedora: https://docs.fedoraproject.org/en-US/modularity/making-modules/ . EPEL is probably (maybe?) similar. I suggest asking on the epel-devel https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/ mailing list. ps.: I'm also very interested in getting a newer CMake onto CentOS, I would just like for it to be done "right" so that it sticks.
(In reply to Tom Stellard from comment #7) > The plan for providing new cmake versions in RHEL8 is to use modules. I > would recommend this for EPEL as well if possible. Otherwise, I think it > would make sense to rename the cmake3 package in EPEL to cmake3.17. Having > a cmake3 package when the base version is already 3.x seems confusing to me. I'm not sure that this makes sense. CMake 3.x (unlike 2.x before it) is enormously backwards compatible. Moreover, non-default module streams are difficult to use in EPEL, since this forces EPEL packages to switch to modules in order to use it. Can't we just have CMake regularly rebased?
(In reply to Neal Gompa from comment #14) > (In reply to Tom Stellard from comment #7) > > The plan for providing new cmake versions in RHEL8 is to use modules. I > > would recommend this for EPEL as well if possible. Otherwise, I think it > > would make sense to rename the cmake3 package in EPEL to cmake3.17. Having > > a cmake3 package when the base version is already 3.x seems confusing to me. > > I'm not sure that this makes sense. CMake 3.x (unlike 2.x before it) is > enormously backwards compatible. Moreover, non-default module streams are > difficult to use in EPEL, since this forces EPEL packages to switch to > modules in order to use it. > > Can't we just have CMake regularly rebased? +1
Well four months later there's been a lot of discussion, but no action I'm aware of. I propose that as a stop-gap, how about a "cmake-latest" EPEL package that conflicts with the base cmake package? I don't think the work of making it parallel installable is worth it. You're not likely to need a lower version of CMake. Or even based on the recent email list discussion, "cmake-next" (haha).
We're planning to rebase CMake to version 3.18.2 in RHEL 8.4 (note that this is a plan, not a firm commitment), please watch bug 1816874 for updates (probably not much that's publicly visible at this point).
I'm closing this as a duplicate of bug 1816874, we're rebasing to CMake 3.18.2 in RHEL 8.4. Feel to reopen in case I missed any aspects that are not covered by bug 1816874 already. *** This bug has been marked as a duplicate of bug 1816874 ***