RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1830748 - Base cmake package erroneously provides "cmake3" and "3" version of binaries
Summary: Base cmake package erroneously provides "cmake3" and "3" version of binaries
Keywords:
Status: CLOSED DUPLICATE of bug 1816874
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cmake
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Tom Stellard
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1756974 1866550
TreeView+ depends on / blocked
 
Reported: 2020-05-03 16:35 UTC by Richard Shaw
Modified: 2021-09-17 08:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-28 10:52:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Richard Shaw 2020-05-03 16:35:44 UTC 
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.
Comment 1 Richard Shaw 2020-05-03 16:36:14 UTC 
I believe this is a leftover from EL 7 where the base cmake package was version 2.
Comment 2 Alexander Korsunsky 2020-05-11 10:11:03 UTC 
> 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.
Comment 3 Richard Shaw 2020-05-11 11:22:09 UTC 
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.
Comment 4 Richard Shaw 2020-05-11 11:25:26 UTC 
(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.
Comment 5 Tom Stellard 2020-05-12 14:20:50 UTC 
Why does EPEL have a cmake3 package?  Isn't the base version already cmake-3.x ?
Comment 6 Richard Shaw 2020-05-12 14:26:58 UTC 
(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.
Comment 7 Tom Stellard 2020-05-12 14:48:57 UTC 
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.
Comment 8 Richard Shaw 2020-05-12 19:19:04 UTC 
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?
Comment 9 Alexander Korsunsky 2020-05-13 08:50:13 UTC 
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.
Comment 10 Richard Shaw 2020-05-13 17:46:42 UTC 
Are EPEL modules possible yet?
Comment 11 Alexander Korsunsky 2020-05-14 10:49:59 UTC 
There is a Modular EPEL repository already: https://bodhi.fedoraproject.org/releases/EPEL-8M
Comment 12 Antonio T. (sagitter) 2020-05-14 10:55:21 UTC 
How are used Modular EPEL repository?
Comment 13 Alexander Korsunsky 2020-05-14 11:09:32 UTC 
(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.
Comment 14 Neal Gompa 2020-05-15 11:35:01 UTC 
(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?
Comment 15 Richard Shaw 2020-05-18 12:20:49 UTC 
(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
Comment 16 Richard Shaw 2020-09-10 11:42:54 UTC 
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).
Comment 17 Tilmann Scheller 2020-09-10 13:46:46 UTC 
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).
Comment 19 Tilmann Scheller 2020-10-28 10:52:55 UTC 
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 ***
Note You need to log in before you can comment on or make changes to this bug.