Can we let the LLVM metapackage diverge between Leap and SLE?
Hi, For a detailed discussion see bugs 1179155 [1] and 1184920 [2]. The gist is that many packages that use LLVM (or Clang or their libraries) tend to use the metapackage "llvm" which in Tumbleweed draws in the latest version of the package, currently llvm11. (It doesn't contain any files itself.) That metapackage also exists in SLE and was inherited into Leap. SLE 15 and Leap 15.0 had llvm = 5.0.1, SP1 and Leap 15.1 had llvm = 7.0.1 and for the next version they started to diverge: SP2 is still at 7.0.1 while Leap 15.2 has llvm = 9.0.1. Due to the "closing the leap gap" effort Leap 15.3 has currently llvm = 7.0.1 from SLE 15 SP3. That is a downgrade from 9.0.1 in 15.2 and would surely disappoint some users (for example of C++ IDEs using libclang). SUSE isn't willing to update the metapackage in SLE, so I'd ask that we keep the divergence and go with the latest version available in Leap, 11.0.1. Is there some process to approve this? And can this even work? It would of course only affect packages in openSUSE:Backports:SLE-15-SP3 and not in the SLE base, but most packages using LLVM are in Leap, and some of those in SLE are hardcoding newer LLVM versions instead of the metapackage. (Like Mesa requiring llvm11 directly.) We discussed this a bit on the bug report, though the nature of OBS makes it hard to say exactly which packages use the metapackage. Best regards, Aaron [1] <https://bugzilla.opensuse.org/show_bug.cgi?id=1179155> [2] <https://bugzilla.opensuse.org/show_bug.cgi?id=1184920>
On 2021/04/19 16:27, Aaron Puchert wrote:
Hi,
For a detailed discussion see bugs 1179155 [1] and 1184920 [2]. The gist is that many packages that use LLVM (or Clang or their libraries) tend to use the metapackage "llvm" which in Tumbleweed draws in the latest version of the package, currently llvm11. (It doesn't contain any files itself.) That metapackage also exists in SLE and was inherited into Leap. SLE 15 and Leap 15.0 had llvm = 5.0.1, SP1 and Leap 15.1 had llvm = 7.0.1 and for... SP2, is at 7.0.1 & 15.2 has llvm = 9.0.1.
Due to the "closing the leap gap" effort, SLE 15_SP2 AND Leap 15.3 have llvm = 7.0.1 (!)
From SLE 15 SP3, that is a downgrade...
That is one of the reasons I decided once-upon-a-time why I thought TW might be a better fit in some ways than Leap -- Due to various circumstances, the latest version of some product in Leap might be multiple releases behind "the latest", where I might be seeking a bug fix or feature from a contemporary release, not one from several months or more ago.
Is there some process to approve this? And can this even work?
Yeah, similar but different problems. Namely -- when latest released package in a version-based Leap or SLE gets too far behind the outside version (which is more likely to be reflected in TW), I might be seeing TW as preferable to various 'version-based-releases' if they are more than 1 major release behind an outside project. I'm pretty sure other projects have been in simlar places to llvm (in the past, was seeing version-based releases of the Gnu-compiler chain in the gcc4.x range, while new releases from the vendor were maybe @ gcc7.x or more). Not the only example that I think there has been over the history of a rolling rel. vs. a version-based release like SLE & Leap. A feeling of wanting something faster than a version- based release might be felt by more than just myself when the delta between released & latest becomes too great. (and when other SLE pkgs might hard code latest vs. released version). Maybe there needs to be a better way to push version-based releases ahead, in general, so as to keep up with externalities?
Am 20.04.21 um 22:07 schrieb L A Walsh:
I'm pretty sure other projects have been in simlar places to llvm (in the past, was seeing version-based releases of the Gnu-compiler chain in the gcc4.x range, while new releases from the vendor were maybe @ gcc7.x or more). Not the only example that I think there has been over the history of a rolling rel. vs. a version-based release like SLE & Leap.
With the difference that SUSE is massively involved in GCC development. Not so much with LLVM, and when it comes to me I'm not sure if I'm willing or able to debug issues in LLVM 7 (version 12 came out a few days ago). With a newer version I can at least see if trunk has it fixed and then try a backport, or file a bug, but with an old version that can get difficult.
participants (2)
-
Aaron Puchert -
L A Walsh