Thomas Klausner <wiz%NetBSD.org@localhost> writes: > Attached you can find an update for the llvm-related packages to the > current release, 13.0.0. > > I've tested it using meta-pkgs/bulk-test-llvm. On NetBSD 9-stable amd64, I would presume, as that is in my view the most important pkgsrc target? But maybe you used netbsd-current and that's not so different in how this will go, although the base gcc is older. If it hasn't been tested on NetBSD-9/amd64 it would be good if someone could do that, also aarch64, and non-NetBSD. At this point I am no longer concerned with how complicated or desktoppy stuff in pkgsrc works on NetBSD 8. 9 has been out for 21 months. But if anybody does, they probably should test and report. > I have not committed it yet because: > > [some breakage] It seems like a fair bit of the breakage is fixed already, and some of it is in the category where we can't reasonably block updating (an upstream has a recent track record of not making releases that work with recent llvm), so the residual breakge is pretty small. It seems good to have this in, as we're already having a bit of rust-llvm trouble. On the other hand, it's only been out 6 weeks and is a .0, so we are hardly behind for not having it. I think the real philosophical question for these updates is whether it's a reasonable expectation that projects that depend on llvm (or any A that depends on B) is expected to be tracking B-current and ensure that when B has a release, then within some shortish time period, maybe 4 weeks, there is an A release that works with the B release. Part of that can be if B is stable enough that it's almost always the case that a new B works fine with any actually-maintained A's most recent release. My impresssion is that llvm has a good track record of not making breaking changes and we are dealing with a combination of unmaintained projects and projects that by their nature have to rely on private interfaces. Is that a fair characterization?
Attachment:
signature.asc
Description: PGP signature