Comment # 7 on bug 1164454 from Richard Biener

(In reply to Aaron Puchert from comment #6)
> (In reply to Richard Biener from comment #1)
> > What's the solution for Factory here?  Ah, we update the old package to
> > no longer build libcxx and python3-clang.
> Correct, this is documented in README.packaging in the llvm metapackage.
> (Perhaps not the place one would expect it...)
> 
> > Note applying the Factory solution to SLE would mean updating llvm7 in
> > SP2 and thus splitting it, requiring future maint updates to be done
> > twice, once for SP1 and once for SP2+ which doesn't sound appealing to me.
> Are the packages otherwise shared between SPs? Because Leap has different
> repos, as far as I know. And so far I didn't run into rebase conflicts
> because of turning off the libc++ builds for older packages.

Yes, in SLE the actual binary rpm packages are shared.

> By the way, we should also update the llvm metapackage
> (https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm), so that
> llvm9 would be used by most packages. I don't think that defaulting to the
> old version is a good idea.
> 
> There was also a major version update to LLVM between Leap 15.0 and 15.1,
> specifically from 5 to 7. So I don't think there is anything new here. We'd
> just need to repeat what was done back then.

This was also done for SLE15 SP1 but there llvm5 was not adjusted (the
issue doesn't arise there since the setup is different - a service pack
is just a set of update rpms ontop of the GA product).  If we ever need
to update llvm5 we'd need to disable the pieces that would otherwise conflict.

> So I'd prefer the Factory solution for Leap 15.2: disable the libc++ &
> python-clang builds for llvm7, update the llvm metapackage to 9.0.1.

That works for me but then the origin should be the Factory packages
rather than the SLE ones.  Note that in SLE15 SP2 we have quite some
packages that use clang/llvm-devel and all of those (but Mesa!) still
use llvm7 - I'm not sure whether they build if we update the 'llvm'
package or which one would need adjustment to build-require llvm7/clang7
variants.  This and because the "update" for SP2 was late is the reason
I refrained from touching the 'llvm' meta-package and made sure we only
use llvm9 from Mesa (where it was requested as a feature) for SP2.

I also wonder if we want to drop llvm5/7 from Leap 15.2 if we introduce
llvm9.

But as said all this is quite some work and I currently have no spare
cycles for a proper solution in Leap.

We can of course try pulling llvm and llvm9 from Factory into a staging
and see what breaks...