After the recent problems with an libLLVM update (which seem reminiscent of a few branches ago, but my memory is slightly fuzzy), it's clear that we need a more careful approach to dealing with libLLVM. This note outlines possible approaches -- but note that the libLLVM package itself will not be changed until the branch is cut. I would like to come to consensus before we make any changes at all. * Updating a package named libLLVM Before updating libLLVM, we'll need to have tested at least MesaLib, rust, and openjdk7/openjdk8. This may lead to delayed updates, but I think that's ok. * Multiple libLLVM versions As usual, we should either have a single version with no suffix, if libLLVM can be sensibly maintained that way, or only versions with suffixes, if we will want to have multiple version at least every year or so. It may be that we do want to have multiple versions, so that different depending packages can use different libLLVM versions. But, it may also be true that waiting until Mesa/rust/openjdk can all use a new version is also a perfectly good strategy, in terms of lack of harm of not jumping on a major vewsion upgrade so soon. It looks like libLLVM34 installs to a different prefix, so that libLLVM34 and libLLVM can be installed at the same time. If that's really true, then multiple versions of libLLVM are feasible. If so, we should add libLLVM4 and libLLVM5, remove libLLVM, and point each of Meas/rust/openjdk at the highest version that works. It is not clear if there are any reasons to keep libLLVM34. There are two packages in wip that use it. It's not clear if users want to use it other than to build other pkgsrc packages.
Attachment:
signature.asc
Description: PGP signature