tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: llvm update to 13.0.0

Thomas Klausner <> 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

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

Home | Main Index | Thread Index | Old Index