On 08.11.2021 12:18, Michał Górny wrote: > Hi, > > A few years back I've slotted LLVM and Clang to make the life with > revdeps easier. Long story short, every major LLVM release (which > happens twice a year) breaks API and it takes some time for revdeps to > adjust. Slotting made it possible to install multiple versions > simultaneously, and therefore let "faster" packages use newer LLVM > without being blocked by "slower" packages on the user's system. > > Unfortunately, this ended up pretty bothersome to maintain. Besides > making ebuilds quite complex (and prone to mistakes), I'm hearing more > and more reports of programs being broken through getting multiple LLVM > versions in the link chain. > > This is not something that can be easily solved. In other words, it's > a mess and I don't think we're really getting anywhere. For this > reason, I'm considering dropping slotting and going back to permitting > only a single version of LLVM and Clang being installed. > > This would have two major implications: > > 1. If you installed any package that requires older LLVM, it'd block all > other packages from updating. If you hit two packages that do not have > a common supported LLVM version, you won't be able to install them > at all. > > On the plus side, this will motivate developers to actually start fixing > these packages rather than letting them rot until I start removing old > LLVM versions. > > 2. We will no longer support having multiple clang versions installed. > While it was convenient for testing stuff, it's not really a killer > feature though. > > The only real alternative I see is actively limiting supported LLVM > versions in packages to ensure that all libraries in the depgraph end up > using the same LLVM version. However, I don't think it's really worth > the effort. > > I don't have a ready unslotting plan yet. > > WDYT? > > -- > Best regards, > Michał Górny > >
This can block rust and consumers quite badly. Currently in rust source ebuild we lock llvm version for system llvm to exact one bundled by upstream, for example 1.55 - llvm12 (with/without system-llvm set) 1.56 - llvm13 (with/without system-llvm set) that's effective with both system-llvm set or unset, and for rust-bin. in theory I can unlock rust version and provide compatibility with multiple, but we run into next problem: rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm rust-bin only can use llvm13 (internal one, pre-compiled by upstream) this will break firefox and spidermonkey and thunderbird on some systems. mozilla products need to be compiled and linked with the same llvm version in all components. compiling/linking firefox with llvm13/clang13, but rust-1.55 will not be possible, because of mis-matched llvm versions. or it may work but break at runtime. and if we have multiple llvm possible in firefox it will not be able to enforce dependency chain via portage. well, we could introduce llvm-ver useflags for rust, and clang, so firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of required-use boilerplate, but that's _very_ ugly. -- Best regards, Georgy
