Re: [gentoo-dev] [RFC] Un-slotting LLVM
On Tuesday, 9 November 2021 2:41:53 PM NZDT Sam James wrote: > > On 8 Nov 2021, at 11: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. > > I think this might just be Blender and friends which are especially fragile. > > We may be able to get away with just coordinating those together. > > > WDYT? > > If we can help it, I'd really really prefer we don't. Being able to test > various different various of Clang quickly (just like gcc) is really > helpful. > I agree. Personally, it's allowed me to narrow down a few bugs in programs/ test suites which only occur with specific LLVM/Clang versions. While I could just build the different versions locally, slotting in combination with package.env really has made testing easier. > (especially given one day, we might dare to dream of using Clang > for the system toolchain. It becomes a lot easier to check for > regressions if you can just flip the version.) > I'd love to see this one day :-) > Best, > sam signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Un-slotting LLVM
> On 8 Nov 2021, at 11: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. I think this might just be Blender and friends which are especially fragile. We may be able to get away with just coordinating those together. > WDYT? If we can help it, I'd really really prefer we don't. Being able to test various different various of Clang quickly (just like gcc) is really helpful. (especially given one day, we might dare to dream of using Clang for the system toolchain. It becomes a lot easier to check for regressions if you can just flip the version.) Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-portage-dev] [PATCH] Install example repo.postsync.d script into sharedir
On 11/4/21 02:50, Daniel Cordero wrote:
The sysconfdir is for host specific configuration files, and this
example script makes no host specific change (it is not enabled by
default).
Install the script under portage's sharedir, from where administrators
can copy it into sysconfdir, if needed.
Signed-off-by: Daniel Cordero
---
setup.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/setup.py b/setup.py
index 549fff650..fe0265c64 100755
--- a/setup.py
+++ b/setup.py
@@ -833,12 +833,12 @@ setup(
["$portage_setsdir", ["cnf/sets/portage.conf"]],
["$docdir", ["NEWS", "RELEASE-NOTES"]],
["$portage_base/bin", ["bin/deprecated-path"]],
-["$sysconfdir/portage/repo.postsync.d",
["cnf/repo.postsync.d/example"]],
+["$portage_confdir/repo.postsync.d",
["cnf/repo.postsync.d/example"]],
],
[
("etc", "cnf", ("etc-update.conf", "dispatch-conf.conf")),
("etc/logrotate.d", "cnf/logrotate.d", ("elog-save-summary",)),
-("etc/portage/repo.postsync.d", "cnf/repo.postsync.d",
("example",)),
+("share/portage/config/repo.postsync.d", "cnf/repo.postsync.d",
("example",)),
(
"share/portage/config",
"cnf",
Merged, thanks!
https://gitweb.gentoo.org/proj/portage.git/commit/?id=b7dc908a99e564de6f10174b1489028d939b917f
--
Thanks,
Zac
Re: [gentoo-dev] [RFC] Un-slotting LLVM
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
Re: [gentoo-dev] [RFC] Un-slotting LLVM
Am Montag, 8. November 2021, 12:18:30 CET schrieb Michał Górny: > WDYT? Not a Gentoo dev but a user who develops software. I find it pretty convenient to have multiple LLVM versions available. I'm developing software that links against LLVM and can test it against multiple versions pretty easy with the current setup. I can evaluate a new LLVM version before switching my own software to it. I can even test some old (already bit-rotted) software that needs an old LLVM version since Gentoo provides it. I'm pretty sure that this argument also holds for all users that want to test their software against multiple versions of Clang (just the same as it holds for slotted GCC). To summarize: Slotted LLVM is not only a feature for other distribution packages but also for users of Gentoo that develop software in compiled languages. > I'm hearing more > and more reports of programs being broken through getting multiple LLVM > versions in the link chain. I'm actually experienced this, but slotted LLVM was a solution here not a problem. Let me explain the link chain (an arrow means: "link against"): my tool --> an unpackaged third party lib (bound to an old LLVM) -> LLVM 10 ´-> graph-tool -> matplotlib -> Mesa (with AMD graphic card) -> LLVM 12 (system default) So my tool depends on a third party lib which needs LLVM 10 (without an easy port). But as I also have an AMD graphic card so my Mesa is compiled with libLLVM for AMDGPU which loads LLVM 12. My tool uses graph-tool which at the end loads Mesa. As a result my LLVM versions conflicted. My fix was to modify the Mesa ebuild to use LLVM 10 as well. This would have been possible without slotted LLVM, but then I has to use LLVM 10 for everything in my system. I'm also not sure, if this would be possible on any other distribution (without containerizing stuff). (In the meantime the third party lib has updated its code to LLVM 12 so everything is fine again.) Best, Gerion signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-python/llvmlite
# Michał Górny (2021-11-08) # Blocked on LLVM 11. Upstream does not handle adding support for new # LLVM or Python versions timely. No reverse dependencies. # Removal on 2021-12-08. Bug #822435. dev-python/llvmlite -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Un-slotting LLVM
This would stop other projects from working where they have their own llvm port, cough rocm cough. On 08/11/2021 11: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?
Re: [gentoo-dev] [RFC] Un-slotting LLVM
On 08/11/2021 12.18, Michał Górny wrote: WDYT? I like slotted LLVM (and GCC) and always find it an advantage over other distributions where it is not so easy to install multiple versions of LLVM (and GCC). It would be unfortunate to see this go. I also can not remember when I last had problems with simultaneously installed LLVM versions as a user. Furthermore, un-slotting LLVM would mean that dev-util/include-what-you-use (IWYU) users are bound to the LLVM version used by IWYU. Which, in turn, means that they are also bound to the corresponding clang-tidy version. Sure, this is nothing that can not be solved by manual user intervention, e.g., users manually installing a newer clang-tidy version. But still, it would not be as easy and convenient as before. That said, I think it's mostly, if not wholly, up to the maintainer. And since you already do a lot of Gentoo work, it may also be a win if we reduce your LLVM workload. - Flow
[gentoo-dev] [RFC] Un-slotting LLVM
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
