This is going to conflict with the CentOS cmake package as it currently "provides" cmake3... And mock is being stupid. Even if I manually install this package in the buildroot, mock still tries to install "cmake"
# 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
I assume this is a leftover from EL 7 where cmake was on version 2.
Worse, the CentOS package provides "3" versions of all the binaries:
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
This package conflicts with provided ./rhel-8-for-x86_64-appstream-rpms/Packages/c/cmake-3.11.4-3.el8.x86_64.rpm which provides cmake3 and contains the packages
The only way I can see this being allowed in EPEL would be for the EPEL cmake3 package being called cmake3.17 and not conflicting with the above files.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
This is not a RHEL bug, you are trying to create the same package with a newer version number.
The cmake vs cmake3 split made sense in EPEL 7 where the base repos had CMake 2 and the EPEL repos had CMake 3. This does not make sense anymore, since the cmake package in the base repos already is version 3.
How does it make sense for there to be "cmake" and "cmake3" packages at the same time, when both are version 3?
The only right move here would be to create a module that contains the "cmake" package, but overrides the base version. This is exactly the situation that modules should be good for.
BZ#1756974 Please package a newer version of CMake (currently 3.15) into EPEL 8
I was able to install that package (cmake3 v3.17), admittedly first removing the RHEL cmake one.
Newer versions of cmake (v3.15+) are really needed.
While I fully understand why the ABI of runtime libraries must not be upgraded/bumped during the lifetime of a LTS (Long Term Supported) distribution, I am less convinced of the rationale of keeping build tools like cmake well behind. Users of the distributions are not negatively impacted by upgrades of build tools such as cmake. On the contrary, the users of build tools are by design developers (C/C++ developers in the case of CMake), and keeping the build tools outdated just add on the burden to maintain packages, obliging us to constantly backport bug fixes on both the upstream packages and on the build tools themselves. Maintaining my own packages with cmake 3.11 on EPEL is practically impossible, now that upstream has realized the benefit of CMake v3.15+, especially when it comes to support of Python 3 and latest Boost libraries: the CMake support files have been drastically re-worked and no longer compatible with older versions of CMake, including cmake 3.11.
So, if CMake is not upgraded on EPEL, I will have to abandon the maintenance of most of my own packages there.
Hopefully we will find a solution. Let's be it if it is with modules, fair enough. I would then be grateful if someone be kind enough to explain how to make use of it once the new CMake modules are properly cooked :)
Strange situation indeed. If we go the module route then it should be in the "cmake" dist-git not "cmake3", but do we need an epel8 branch? If so how do we ask? I assume if we requested one it would get denied as it exists in RHEL/CentOS...
This update has been submitted for testing by sagitter.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
Thanks for that contribution!
This is going to conflict with the CentOS cmake package as it currently "provides" cmake3... And mock is being stupid. Even if I manually install this package in the buildroot, mock still tries to install "cmake"
I assume this is a leftover from EL 7 where cmake was on version 2.
Worse, the CentOS package provides "3" versions of all the binaries:
Reported:
https://bugs.centos.org/view.php?id=17318
I don't know why they need to install all binaries with as 3 or use
Provides: cmake3 = 3.11.4-3.el8, unless CMake-2 is still provided by CentOS 8.This prevents any
CMakeadditional updated package.This package conflicts with provided ./rhel-8-for-x86_64-appstream-rpms/Packages/c/cmake-3.11.4-3.el8.x86_64.rpm which provides cmake3 and contains the packages
/usr/bin/ccmake3 /usr/bin/cmake3 /usr/bin/cpack3 /usr/bin/ctest3 /usr/lib/.build-id
The only way I can see this being allowed in EPEL would be for the EPEL cmake3 package being called cmake3.17 and not conflicting with the above files.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
The only other fix I can see with this would be to make a cmake module which would allow for this replacement.
Ok, this is where CentOS is just repackaging RHEL, so really this is a RHEL bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1830748
This package is not installable.
This is not a RHEL bug, you are trying to create the same package with a newer version number.
The cmake vs cmake3 split made sense in EPEL 7 where the base repos had CMake 2 and the EPEL repos had CMake 3. This does not make sense anymore, since the cmake package in the base repos already is version 3.
How does it make sense for there to be "cmake" and "cmake3" packages at the same time, when both are version 3?
The only right move here would be to create a module that contains the "cmake" package, but overrides the base version. This is exactly the situation that modules should be good for.
It's clearly specified in https://bugzilla.redhat.com/show_bug.cgi?id=1756974
This update has been unpushed.
I was able to install that package (cmake3 v3.17), admittedly first removing the RHEL cmake one.
Newer versions of cmake (v3.15+) are really needed.
While I fully understand why the ABI of runtime libraries must not be upgraded/bumped during the lifetime of a LTS (Long Term Supported) distribution, I am less convinced of the rationale of keeping build tools like cmake well behind. Users of the distributions are not negatively impacted by upgrades of build tools such as cmake. On the contrary, the users of build tools are by design developers (C/C++ developers in the case of CMake), and keeping the build tools outdated just add on the burden to maintain packages, obliging us to constantly backport bug fixes on both the upstream packages and on the build tools themselves. Maintaining my own packages with cmake 3.11 on EPEL is practically impossible, now that upstream has realized the benefit of CMake v3.15+, especially when it comes to support of Python 3 and latest Boost libraries: the CMake support files have been drastically re-worked and no longer compatible with older versions of CMake, including cmake 3.11.
So, if CMake is not upgraded on EPEL, I will have to abandon the maintenance of most of my own packages there. Hopefully we will find a solution. Let's be it if it is with modules, fair enough. I would then be grateful if someone be kind enough to explain how to make use of it once the new CMake modules are properly cooked :)
Thanks!
Strange situation indeed. If we go the module route then it should be in the "cmake" dist-git not "cmake3", but do we need an epel8 branch? If so how do we ask? I assume if we requested one it would get denied as it exists in RHEL/CentOS...
I have started a thread on the epel-devel mailing list: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/ICZGG2SQKUTV2JUBAS4XTWX2FQIKZT27/
I hope to get some replies that could gives us some direction.