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: NEW
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: 2020-09-10 16:49 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


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).


Note You need to log in before you can comment on or make changes to this bug.