On January 9, 2021 1:05:51 AM GMT+01:00, Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 08.01.21 um 09:55 schrieb Richard Biener:
One possibility is to not require llvm-devel >= $ver but a specific one (usually the >= will break anyway at some point).
Why would >= break at some point? I see how it could happen for <=, but
as long as versions are increasing, >= should be satisfied into the future.
Of course new versions of LLVM tend to need changes in Rust, but upstream is usually quick to provide them.
Yes, that was the point I tried to make. Require a known to work version.
For Leap 15.3 llvm9-devel should work as well as llvm11-devel. Note you're not going to have the 'llvm-devel' style symlinks but have to use version specific tool names (whatever they are). Mesa is using llvm11 via such mechanism for 15.3.
That should work, though I'm not a big fan of this. I'd rather have most packages use llvm-devel because otherwise they're going to use random versions of LLVM depending on when the maintainer last thought about incrementing the version.
Another problem is that libLLVM.so didn't behave so well in the past when multiple versions of the library were loaded into a process. That's why it's good to have a "standard version" and make sure that at least libraries use that. (That would include Mesa for example.)
By the way, the symlinks are always there because they are provided by update-alternatives. But they might not point to the version you wanted, because update-alternatives defaults to the newest version and if you're getting a newer version via transitive dependencies, it will use that instead.
For Leap 15.3 we will have differing 'llvm' packages I'm sure (not defaulting to llvm7 but llvm11).
Perhaps the solution here is that we inherit the llvm{7,9,11} packages from SLE but not the llvm metapackage. Not sure if that's possible. Perhaps we should also not inherit llvm5, since I removed that from Leap 15.2 already [2] and there is no reason to reintroduce it in my view.
I have no hopes for a simple solution ;) Note for SLE you can't remove packages :/ But since Leap 15.3 is at least an alternate media we can possibly block them to not appear there.
Just to be clear, llvm is much more important than llvm5 in my opinion.
Ideally SUSE could just be convinced to update llvm as it was done between SP0 and SP1, but I'm not sure if anybody complained about that,
or what the reasons are to not do it now.
It was a mistake to provide llvm/clang at all for SLE (ship on the product) because we cannot support it to the level expected. Starting with llvm9 we provide it only to select packages (Mesa) where we can. But we can't just drop the old llvm package and direct people to packagehub for it, even though that's what I'd prefer... _maybe_ closing the leap gap is an excuse to do that now but the pandemic makes office floor politics a lot harder... Richard.
Best regards, Aaron