Comment # 14 on bug 1221183 from Aaron Puchert

(In reply to Aaron Puchert from comment #9)
> The earlier SPs had updates for the metapackage, but there is some reason
> specific to how SLE is built that made it uncompelling to update it for
> later SPs.

Now I remember: the problem is that SLE doesn't rebuild packages unless there
are updates to the sources. That's why the metapackage doesn't work in the
expected way: updating the metapackage in Factory or Backports means that all
packages using it are being rebuilt, but in SLE that's not the case. Packages
continue to use the old LLVM version unless they get an update after the
metapackage update, and then they will use the new version.

In other words: using the metapackage on SLE is basically also just pinning to
a specific version, but it's not hardcoded in the specfile. It depends on the
build date. Because of that, we'd rather have packages in SLE make an explicit
static choice, which doesn't functionally change anything, but makes it clear
what is actually being used.

(In reply to Richard Biener from comment #12)
> There is a request to drop the llvm meta package from SP6 repositories as
> well (PED-7373), I hope this extends to Leap and we can instead pull the
> one from backports there.

Leap's metapackage should shadow the one from SLE, so I don't expect any issues
in Backports when removing SLE's metapackage.

(In reply to Franz Sirl from comment #13)
> Well, that's a bit unfortunate for non-SUSE OBS users like me building
> newer/extended versions of SLE packages.

SUSE OBS users have pretty much the same issue. For example, Mesa and related
packages (like libclc) also pin LLVM versions for SLE. Another example is
bpftrace:

 # Hard-code latest LLVM for SLES, the default version is too old
 %if 0%{?sle_version} == 150600
  %define llvm_major_version 17
 %else
 %if 0%{?sle_version} == 150500
  %define llvm_major_version 15
 %else
 %if 0%{?sle_version} == 150400
  %define llvm_major_version 11
 %endif
 %endif
 %endif

> To highlight the problem, for example I would like to enable libclang
> support for doxygen by default via a pull request
> (https://build.opensuse.org/repositories/home:fsirl:doxygen-libclang), but I
> don't want to put that maintenance burden vs SLE on the devel:tools
> maintainer.

Since devel:tools builds against 15.5 and 15.6, it should be easy to see
breakage. And the newest LLVM version in SLE 15 SPx is basically always 2*x +
5, with the exception of SP4 where llvm13 didn't end up in SLE but only in
Backports. But otherwise the release schedules have so far aligned perfectly.