|Summary:||Please upgrade the non-modular CMake package instead of releasing this module|
|Product:||Red Hat Enterprise Linux 8||Reporter:||Neal Gompa <ngompa13>|
|Component:||cmake-rhel8-module||Assignee:||Tom Stellard <tstellar>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Martin Cermak <mcermak>|
|Version:||CentOS Stream||CC:||a.korsunsky, bstinson, carl, denis.arnaud_fedora, fedoraproject, igor.raits, jwboyer, mnewsome, pasteur, phil, quent.haas, tschelle|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2020-07-31 10:18:06 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Neal Gompa 2020-06-10 12:11:01 UTC
Description of problem: The upcoming module for CMake in RHEL 8.3 (pushed to CentOS Stream last night) is unnecessary and unhelpful. It is impossible to use from EPEL, as it's a non-default module that conflicts with the base OS version. Please upgrade the regular CMake package instead of releasing this module. CMake has maintained excellent backwards compatibility since starting their new behavior policy in CMake 3.0, and upgrading the regular CMake package rather than making a module would improve the usability of this for downstream consumers.
Comment 1 Carl George 🤠 2020-06-10 16:52:57 UTC
I agree with Neal. Having a bare cmake 3.11 and a modular cmake 3.17 is only going to lead to customer confusion. Additionally, any package that needs to use the newer version of cmake will be forced to also use modularity, regardless if it makes sense for their package. Modularity is a useful technology, but it needs to only be used when it makes sense.
Comment 2 Tom Stellard 2020-06-30 02:22:11 UTC
(In reply to Neal Gompa from comment #0) > Description of problem: > The upcoming module for CMake in RHEL 8.3 (pushed to CentOS Stream last > night) is unnecessary and unhelpful. It is impossible to use from EPEL, as > it's a non-default module that conflicts with the base OS version. > > Please upgrade the regular CMake package instead of releasing this module. > CMake has maintained excellent backwards compatibility since starting their > new behavior policy in CMake 3.0, and upgrading the regular CMake package > rather than making a module would improve the usability of this for > downstream consumers. Is this new behavior policy documented somewhere?
Comment 3 Neal Gompa 2020-06-30 07:20:20 UTC
There is a document that talks about CMake policy behavior, and the cmake-policies(7) man page describes all of the policies CMake offers. Virtually all CMake scripts set a cmake_minimum_required value, which implicitly sets the cmake_policy value that configures CMake's behavior. This mechanism is what ensures CMake remains compatible as it is upgraded, and this has been more strongly enforced since CMake 3.0. : https://cmake.org/cmake/help/latest/command/cmake_policy.html : https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html : https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html
Comment 4 Quentin Haas 2020-07-14 15:26:20 UTC
As mentioned over in the EPEL8 plea for newer cmake, I appreciate that RH is addressing the need for newer versions of cmake as more and more projects seem to be breaking with 3.11, especially CUDA based ones... having to recompile, especially on Power, for cmake 3.14+ is time consuming/annoying. I am a bit surprised that the default version of cmake in EL8 is but 3.11. As Neal pointed out, if the maintainers of cmake can guarantee backwards compatibility with newer minor releases of 3.x, why not update to newer minor releases? : https://bugzilla.redhat.com/show_bug.cgi?id=1756974
Comment 5 Neal Gompa 2020-07-19 13:39:42 UTC
It would be extremely helpful now if the non-modular CMake package is upgraded, especially because the functionality that the new Fedora macros introduced with Fedora 33 and backported to Fedora 31 and 32 requires at least CMake 3.15. I've proposed a PR to incorporate this into the modular CMake package, but I really want to see this pushed into the non-modular CMake package. I'm still trying to figure out some kind of hack to do this with CMake 3.11, and that'll likely exist for a short while (but probably not as nice as what we have for Fedora), but I'd like to eliminate it with RHEL 8.3's release. : https://git.centos.org/rpms/cmake/pull-request/1
Comment 6 Neal Gompa 2020-07-19 13:42:13 UTC
(In reply to Quentin Haas from comment #4) > As mentioned over in the EPEL8 plea for newer cmake, I appreciate that RH > is addressing the need for newer versions of cmake as more and more projects > seem to be breaking with 3.11, especially CUDA based ones... having to > recompile, especially on Power, for cmake 3.14+ is time consuming/annoying. > I am a bit surprised that the default version of cmake in EL8 is but 3.11. > Note that CUDA projects will likely start forcing CMake 3.18 because that release includes CUDA-specific enhancements. : https://cmake.org/cmake/help/v3.18/release/3.18.html
Comment 7 Tilmann Scheller 2020-07-23 15:48:37 UTC
Thanks everyone for the feedback, we have decided to remove this newly introduced CMake module from RHEL 8.3. Our plan (not a firm commitment at this stage) is to rebase system CMake in RHEL 8.4 instead. Hopefully this will help to address the concerns that have been raised in this bug.
Comment 9 Tilmann Scheller 2020-07-31 10:18:06 UTC
The CMake module has been removed RHEL 8.3 now, closing this bug. Bug 1816874 is used to track any future work (e.g. possibly updating system CMake in RHEL 8.4).
Comment 11 Denis Arnaud 2020-08-01 00:53:41 UTC
(In reply to Tilmann Scheller from comment #9) > The CMake module has been removed RHEL 8.3 now, closing this bug. Bug > 1816874 is used to track any future work (e.g. possibly updating system > CMake in RHEL 8.4). Is there a way for Fedora/CentOS/EPEL packagers to access that bug request (https://bugzilla.redhat.com/show_bug.cgi?id=1816874), even though we are not Red Hat customers? As many other developers and packagers, maintaining my own packages on CentOS 8 with CMake 3.11 becomes impractical. And CMake 3.17+ is already available on EPEL 7. So, offering CMake 3.11 as the latest version on CentOS 8 seems weird, to tell the least.
Comment 12 Tilmann Scheller 2020-08-13 14:53:21 UTC
Apologies for the delay, I've made the bug public now. I assume you won't be able to see a lot of content yet but we'll update the bug with public comments as good as we can. Thanks!