Bug 2079833
Summary: | [tracker] Get rid of multiple source path definitions | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Schorm <mschorm> |
Component: | cmake | Assignee: | Björn Esser (besser82) <besser82> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 37 | CC: | bcotton, besser82, cllang, jreznik, lzaoral, mhroncok, rdieter, sanjay.ankur, trpost, walter.pete |
Target Milestone: | --- | Flags: | bcotton:
fedora_prioritized_bug+
|
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-08-24 15:35:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2045824, 2057738, 2059134, 2059188, 2059201, 2061754, 2113510, 2139909 |
Description
Michal Schorm
2022-04-28 10:48:12 UTC
Remove the second source path definition from the CMake command The '%cmake' RPM macro in Fedora actually expands to: | ... | /usr/bin/cmake \ | -S "." \ | -B "redhat-linux-build" \ | ... So in this case the source patch was specified twice. First in the macro with the '-S' option and second time outside of the macro, in the SPECfile, without the '-S' option. CMake upstream declares that: | This has never been officially documented or supported, | but older versions accidentally accepted multiple source paths | and used the last path specified. Update scripts to avoid | passing multiple source path arguments. https://cmake.org/cmake/help/v3.23/release/3.23.html#deprecated-and-removed-features This was discovered as CMake upstream implemented a change to the 3.23.0-rc2 release that changed this behavior and it broke many Fedora packages that used this double source path definition. See rhbz#2057738 to see how build behaved After the CMake upstream got aware of what problems it caused in Fedora, they opened a merge request to restore the behavior to the old one, but kept the warnings that that is an unsupported and problematic behavior: https://gitlab.kitware.com/cmake/cmake/-/issues/23334 --- As for today, this issue is still not yet fully resolved. - The CMake maintainers in Fedora haven't rebased the package to 3.23-1 release, so it is still broken - Affected packages in Fedora should find a way to stop using this unsupported behaviour - The double '-S' argument passing should be marked as problematic too, in the exact same way https://gitlab.kitware.com/cmake/cmake/-/issues/23334#note_1159258 - A change to the %cmake Fedora RPM macro might be in play, so it won't force a source path https://gitlab.kitware.com/cmake/cmake/-/issues/23334#note_1159258 Nominating as a prioritized bug. This still causes too much friction, see e.g. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FEKQKSOF5DA6WQ4CD2I6M5VJ7QBTSO6X/ In today's Prioritized Bugs meeting, we agreed to accept this as a prioritized bug due to the impact on package maintainers. cmake maintainers should update with the upstream package and submit a System-Wide Change proposal for future releases where upstream re-implements this or similar change that require coordination with other packagers (as outlined in the Rawhide updates policy https://meetbot.fedoraproject.org/fedora-meeting-1/2022-06-15/fedora_prioritized_bugs_and_issues.2022-06-15-14.00.log.html#l-83 Björn, do you have an update on this? Is there something Matthew or I can do to get you the resources you need to resolve this? I see cmake-3.23.3-1.fc37 landed in Rawhide recently. As I understand it, this should fix (in the short-term, at least) the issue reported here. Can someone please confirm this? I've just tested the meshlab package from before this fix: https://src.fedoraproject.org/rpms/meshlab/c/1423fa94218fb25e88262e263db17b84eba4859d?branch=rawhide It seems to at least get past the point where it initially failed. I've also tested libarcus before https://src.fedoraproject.org/rpms/libarcus/c/5b4abb1317e4020b5f903679611dc4b2cca498aa?branch=rawhide It seems to build. I don't have enough time to verify this fixes everything here, but it sure seems like the situation has improved. Here is the test on the package 'galera' ----- # fedpkg clone galera && cd galera # grep "%cmake " galera.spec %cmake \ # fedpkg build --scratch --srpm --arches=x86_64 https://koji.fedoraproject.org/koji/taskinfo?taskID=90548809 # git revert 64680cf3405ede44b0fb4f5f4014884e8d3b997a Auto-merging galera.spec [rawhide 2b4fa89] Revert "Remove the second source path definition from the CMake command" 1 file changed, 1 insertion(+), 1 deletion(-) # grep "%cmake " galera.spec %cmake . \ # fedpkg build --scratch --srpm --arches=x86_64 https://koji.fedoraproject.org/koji/taskinfo?taskID=90548814 ----- Both variants (single and double source path definition) succeeded, so the workaround (rebase of the 'cmake' package to a release in which the upstream reverted the change leading to our problems) works. The issue with double source path definitions (where the first one is baked into '%cmake' macro) across the Fedora packages remains. Setting this bug to VERIFIED. At the next Prioritized Bugs meeting (Wed 10 Aug), we'll discuss whether to leave it open. My inclination is to close it as the immediate concern has passed and continue leaning on the cmake maintainers to coordinate a long-term fix for when upstream re-removes the behavior. This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37. In today's Prioritized Bugs meeting, we agreed this is solved enough for our purposes and we encourage cmake maintainers to use the Changes process for future updates to prevent similar issues: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-08-24/fedora_prioritized_bugs_and_issues.2022-08-24-14.00.log.html#l-113 Setting status to CLOSED The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |