| 1 |
On 08.11.2021 12:18, Michał Górny wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> A few years back I've slotted LLVM and Clang to make the life with |
| 5 |
> revdeps easier. Long story short, every major LLVM release (which |
| 6 |
> happens twice a year) breaks API and it takes some time for revdeps to |
| 7 |
> adjust. Slotting made it possible to install multiple versions |
| 8 |
> simultaneously, and therefore let "faster" packages use newer LLVM |
| 9 |
> without being blocked by "slower" packages on the user's system. |
| 10 |
> |
| 11 |
> Unfortunately, this ended up pretty bothersome to maintain. Besides |
| 12 |
> making ebuilds quite complex (and prone to mistakes), I'm hearing more |
| 13 |
> and more reports of programs being broken through getting multiple LLVM |
| 14 |
> versions in the link chain. |
| 15 |
> |
| 16 |
> This is not something that can be easily solved. In other words, it's |
| 17 |
> a mess and I don't think we're really getting anywhere. For this |
| 18 |
> reason, I'm considering dropping slotting and going back to permitting |
| 19 |
> only a single version of LLVM and Clang being installed. |
| 20 |
> |
| 21 |
> This would have two major implications: |
| 22 |
> |
| 23 |
> 1. If you installed any package that requires older LLVM, it'd block all |
| 24 |
> other packages from updating. If you hit two packages that do not have |
| 25 |
> a common supported LLVM version, you won't be able to install them |
| 26 |
> at all. |
| 27 |
> |
| 28 |
> On the plus side, this will motivate developers to actually start fixing |
| 29 |
> these packages rather than letting them rot until I start removing old |
| 30 |
> LLVM versions. |
| 31 |
> |
| 32 |
> 2. We will no longer support having multiple clang versions installed. |
| 33 |
> While it was convenient for testing stuff, it's not really a killer |
| 34 |
> feature though. |
| 35 |
> |
| 36 |
> The only real alternative I see is actively limiting supported LLVM |
| 37 |
> versions in packages to ensure that all libraries in the depgraph end up |
| 38 |
> using the same LLVM version. However, I don't think it's really worth |
| 39 |
> the effort. |
| 40 |
> |
| 41 |
> I don't have a ready unslotting plan yet. |
| 42 |
> |
| 43 |
> WDYT? |
| 44 |
> |
| 45 |
> -- |
| 46 |
> Best regards, |
| 47 |
> Michał Górny |
| 48 |
> |
| 49 |
> |
| 50 |
|
| 51 |
This can block rust and consumers quite badly. |
| 52 |
Currently in rust source ebuild we lock llvm version for system llvm to |
| 53 |
exact one bundled by upstream, for example |
| 54 |
|
| 55 |
1.55 - llvm12 (with/without system-llvm set) |
| 56 |
1.56 - llvm13 (with/without system-llvm set) |
| 57 |
|
| 58 |
that's effective with both system-llvm set or unset, and for rust-bin. |
| 59 |
in theory I can unlock rust version and provide compatibility with |
| 60 |
multiple, but we run into next problem: |
| 61 |
|
| 62 |
rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm |
| 63 |
rust-bin only can use llvm13 (internal one, pre-compiled by upstream) |
| 64 |
|
| 65 |
this will break firefox and spidermonkey and thunderbird on some |
| 66 |
systems. |
| 67 |
mozilla products need to be compiled and linked with the same llvm |
| 68 |
version in all components. |
| 69 |
|
| 70 |
compiling/linking firefox with llvm13/clang13, but rust-1.55 will |
| 71 |
not be possible, because of mis-matched llvm versions. or it may work |
| 72 |
but break at runtime. |
| 73 |
|
| 74 |
and if we have multiple llvm possible in firefox it will not be able to |
| 75 |
enforce dependency chain via portage. |
| 76 |
|
| 77 |
well, we could introduce llvm-ver useflags for rust, and clang, so |
| 78 |
firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of |
| 79 |
required-use boilerplate, but that's _very_ ugly. |
| 80 |
|
| 81 |
-- |
| 82 |
Best regards, |
| 83 |
Georgy |
Archives