Leap 15.3 - Rust and its build time dependencies
Hi there, I am trying to build all packages I'm somehow involved with for Leap 15.3, but fail with "rust". rust-1.47 require llvm-devel >= 8.0 (9.0 since rust-1.48), but this cannot be found for Leap 15.3. As Leap 15.2 comes with llvm-devel-9.0.1 and since Leap 15.3 should provide everything Leap 15.2 has (at least that's my understanding), why is it missing? Can I do anything about this? If so, what? For details just look at the following project and its meta data: https://build.opensuse.org/project/show/home:manfred-h:devel:languages:rust:... https://build.opensuse.org/projects/home:manfred-h:devel:languages:rust:rust... TIA, cheers. l8er manfred
Am 07.01.21 um 17:37 schrieb Manfred Hollstein:
Hi there,
I am trying to build all packages I'm somehow involved with for Leap 15.3, but fail with "rust". rust-1.47 require llvm-devel >= 8.0 (9.0 since rust-1.48), but this cannot be found for Leap 15.3. As Leap 15.2 comes with llvm-devel-9.0.1 and since Leap 15.3 should provide everything Leap 15.2 has (at least that's my understanding), why is it missing? Can I do anything about this? If so, what?
I think that's a fallout of the "Closing the Leap gap" effort and the divergence of Leap and SLE in the LLVM area. SUSE decided to update the "llvm" metapackage from 5 to 7 for SLE 15 SP1, but didn't update for SP2, while in Leap 15.2 we went to 9. It's likely going to stay that way, although I can't say anything about the technical details here [1]:
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. Otherwise Leap 15.3 should have not only llvm9 [3] inherited from SUSE:SLE-15-SP2:Update, but also llvm11 [4] inherited from SUSE:SLE-15-SP3:GA, although I can't find binary packages for the latter in [5]. Best regards, Aaron [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c12 [2] https://build.opensuse.org/request/show/776163 [3] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm9 [4] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm11 [5] https://download.opensuse.org/distribution/leap/15.3/repo/oss/x86_64/
On Fri, 8 Jan 2021, Aaron Puchert wrote:
Am 07.01.21 um 17:37 schrieb Manfred Hollstein:
Hi there,
I am trying to build all packages I'm somehow involved with for Leap 15.3, but fail with "rust". rust-1.47 require llvm-devel >= 8.0 (9.0 since rust-1.48), but this cannot be found for Leap 15.3. As Leap 15.2 comes with llvm-devel-9.0.1 and since Leap 15.3 should provide everything Leap 15.2 has (at least that's my understanding), why is it missing? Can I do anything about this? If so, what?
I think that's a fallout of the "Closing the Leap gap" effort and the divergence of Leap and SLE in the LLVM area. SUSE decided to update the "llvm" metapackage from 5 to 7 for SLE 15 SP1, but didn't update for SP2, while in Leap 15.2 we went to 9. It's likely going to stay that way, although I can't say anything about the technical details here [1]:
One possibility is to not require llvm-devel >= $ver but a specific one (usually the >= will break anyway at some point). 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's how packages like firefox use newer GCC as well, require say gcc10-c++ and build with CXX=g++-10 (or set up your own directory with symlinks for insane build systems and adjust your PATH to prefer that).
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. Richard.
Otherwise Leap 15.3 should have not only llvm9 [3] inherited from SUSE:SLE-15-SP2:Update, but also llvm11 [4] inherited from SLE-15-SP3:GA, SUSE:although I can't find binary packages for the latter in [5].
Best regards, Aaron
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c12 [2] https://build.opensuse.org/request/show/776163 [3] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm9 [4] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm11 [5] https://download.opensuse.org/distribution/leap/15.3/repo/oss/x86_64/
--
Richard Biener
On Fri, 08 Jan 2021, 09:55:02 +0100, Richard Biener wrote:
On Fri, 8 Jan 2021, Aaron Puchert wrote:
Am 07.01.21 um 17:37 schrieb Manfred Hollstein:
Hi there,
I am trying to build all packages I'm somehow involved with for Leap 15.3, but fail with "rust". rust-1.47 require llvm-devel >= 8.0 (9.0 since rust-1.48), but this cannot be found for Leap 15.3. As Leap 15.2 comes with llvm-devel-9.0.1 and since Leap 15.3 should provide everything Leap 15.2 has (at least that's my understanding), why is it missing? Can I do anything about this? If so, what?
I think that's a fallout of the "Closing the Leap gap" effort and the divergence of Leap and SLE in the LLVM area. SUSE decided to update the "llvm" metapackage from 5 to 7 for SLE 15 SP1, but didn't update for SP2, while in Leap 15.2 we went to 9. It's likely going to stay that way, although I can't say anything about the technical details here [1]:
One possibility is to not require llvm-devel >= $ver but a specific one (usually the >= will break anyway at some point). 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.
Thanks for your hints, Aaron and Richard! I'll see if I can convince the rust package maintainers to accept such a change ;) Will try if it works in all situations.
That's how packages like firefox use newer GCC as well, require say gcc10-c++ and build with CXX=g++-10 (or set up your own directory with symlinks for insane build systems and adjust your PATH to prefer that).
Yep, well known example. Cheers. l8er manfred
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.
Richard.
Otherwise Leap 15.3 should have not only llvm9 [3] inherited from SUSE:SLE-15-SP2:Update, but also llvm11 [4] inherited from SLE-15-SP3:GA, SUSE:although I can't find binary packages for the latter in [5].
Best regards, Aaron
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c12 [2] https://build.opensuse.org/request/show/776163 [3] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm9 [4] https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm11 [5] https://download.opensuse.org/distribution/leap/15.3/repo/oss/x86_64/
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.
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. Best regards, Aaron
On January 9, 2021 1:05:51 AM GMT+01:00, Aaron Puchert
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
participants (3)
-
Aaron Puchert -
Manfred Hollstein -
Richard Biener