Bug 1179155 - llvm11 for 15SP3 / Leap15.3
llvm11 for 15SP3 / Leap15.3
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Development
Leap 15.3
Other SLES 15
: P1 - Urgent : Normal (vote)
: ---
Assigned To: Michael Matz
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-24 13:19 UTC by Richard Biener
Modified: 2022-01-12 16:45 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2020-11-24 13:19:38 UTC
I'm opening this bug to avoid repeating bug1164454 - SP3 is supposed to get
an update to the Mesa LLVM stack again, this time I will pick llvm11.  Again
SLE 15 SP3 will keep llvm7 as 'llvm' and from the llvm11 set of packages only
what is required for Mesa will end up on the media (no clang, etc.) but all
this "rest" should be diverted to PackageHub.

Since there's that new Jump thing on the plate for Leap 15.3 and Leap 15.3
traditionally wants clang to be new and not old I wonder how we can make
these conflicting requirements work this time.

My current plan is to simply throw what's in Factory into SP3 and put a big
fat note on it what (sub-)packages to ship and what not.
Comment 1 Aaron Puchert 2020-11-24 23:41:00 UTC
(In reply to Richard Biener from comment #0)
> Again SLE 15 SP3 will keep llvm7 as 'llvm'
Isn't Mesa the only consumer of llvm in SLE?

But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA.
Comment 2 Richard Biener 2020-11-25 08:09:45 UTC
(In reply to Aaron Puchert from comment #1)
> (In reply to Richard Biener from comment #0)
> > Again SLE 15 SP3 will keep llvm7 as 'llvm'
> Isn't Mesa the only consumer of llvm in SLE?
> 
> But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA.

Mesa is currently the only consumer of llvm9 but there are several packages
that use clang/llvm for building (rust for example) and those still use llvm7
via the llvm package.

I'm now trying to sync up the package structure on SLE to what we have on Factory some more, re-syncing at least the llvm9 copy and more carefully llvm7.
Comment 3 Richard Biener 2020-12-02 08:06:26 UTC
For the install check issues below we can either add SLE specific conflicts
(they will not work with factory based llvm7/9 packages and thus likely Leap)
or update the llvm7 stack to the package setup of Factory (there's shuffling
around of binaries into a new clang-tools package) and do the same for llvm9.
I'd rather not split sources in SP3 so updating llvm7 means updating the package
setup for SP1+ and llvm9 means updating for SP2+ (but none of the affected
packages are actually shipped on the media there for llvm9 as opposed to
llvm7 which accidentially got fully shipped for SP1).  For llvm5 of :GA there's
still the hard Conflicts: llvm5 in the Factory packages.

That said, we can also simply ignore the issue since clang-tools is not
supposed to be on the SP3 media (but on PackageHub - where the issue
might or might not be a blocker there)

### [install check & file conflicts for x86_64]

found conflict of clang-tools-11.0.0-3.2.x86_64 with clang7-7.0.1-3.13.1.x86_64
  /usr/bin/clang-format-diff
  /usr/bin/clang-tidy-diff
  /usr/bin/git-clang-format
  /usr/bin/run-clang-tidy

found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm7-7.0.1-3.13.1.x86_64
  /usr/bin/hmaptool

found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm9-9.0.1-3.3.1.x86_64
  /usr/bin/hmaptool
Comment 8 Richard Biener 2020-12-04 07:53:03 UTC
I have submitted a change to llvm7 to Conflict with clang-tools.  I fear we cannot simply update SP2 llvm9 from Factory since that now has clang-tools but does not build them (as it comes from newer llvm there) but we still need it to build Mesa-drivers in SP2 (in SP2 llvm9 is the newest llvm and clang9-devel requires clang-tools).  Note for SP4 we'll have the issue that we have clang-tools from multiple packages but clang-tools isn't versioned :/  The Factory/leap way would be to have separate sources for each llvm version in each product.  Meh.

IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version}
and the Recommends/Requires from clang/clang-devel should be
to clang-tools >= %{version}.  For the OBS solver that might be ambiguous
but GCC solves this with Prefer: in the prjconfs.  At least this avoids
needing to touch packages again and again.

Aaron, would you be opposed to such a change in the Factory packages?
(I'd switch building of individual clang-tools%{_sonum} back on so SLE
could 1:1 use the Factory packages which seems to be a requirement here)
Comment 10 Richard Biener 2020-12-04 13:15:27 UTC
(In reply to Richard Biener from comment #8)
> IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version}
> and the Recommends/Requires from clang/clang-devel should be
> to clang-tools >= %{version}.  For the OBS solver that might be ambiguous
> but GCC solves this with Prefer: in the prjconfs.  At least this avoids
> needing to touch packages again and again.
> 
> Aaron, would you be opposed to such a change in the Factory packages?
> (I'd switch building of individual clang-tools%{_sonum} back on so SLE
> could 1:1 use the Factory packages which seems to be a requirement here)

I've prepped this for llvm11 in home:rguenther:branches:devel:tools:compiler/llvm11

I do have similar issues with libcxx and libabi of course ...
Comment 11 Aaron Puchert 2020-12-13 00:15:03 UTC
(In reply to Richard Biener from comment #3)
> install check & file conflicts for x86_64]
> 
> found conflict of clang-tools-11.0.0-3.2.x86_64 with
> clang7-7.0.1-3.13.1.x86_64
>   /usr/bin/clang-format-diff
>   /usr/bin/clang-tidy-diff
>   /usr/bin/git-clang-format
>   /usr/bin/run-clang-tidy
> 
> found conflict of clang-tools-11.0.0-3.2.x86_64 with
> llvm7-7.0.1-3.13.1.x86_64
>   /usr/bin/hmaptool
> 
> found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm9-9.0.1-3.3.1.x86_64
>   /usr/bin/hmaptool

In Factory clang-tools has

# Some binaries used to be in the clang package.
Conflicts:      clang5
Conflicts:      clang6
# hmaptool used to be contained in the llvm package.
Conflicts:      llvm5
Conflicts:      llvm6

So for llvm7 I'd just add them here. The hmaptool conflict with llvm9 is probably because Leap's llvm9 doesn't have https://build.opensuse.org/request/show/782745, thus clang-tools yet?

(In reply to Richard Biener from comment #8)
> I have submitted a change to llvm7 to Conflict with clang-tools.  I fear we
> cannot simply update SP2 llvm9 from Factory since that now has clang-tools
> but does not build them (as it comes from newer llvm there) but we still
> need it to build Mesa-drivers in SP2 (in SP2 llvm9 is the newest llvm and
> clang9-devel requires clang-tools).
To be honest, I don't like the artificial dependency clangX-devel's CMake files have on binaries. But perhaps this can be solved with https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm9?linkrev=base&rev=42, which allows any clang-tools version. Perhaps you also need https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm9?linkrev=base&rev=56, in case the binaries changed.

> Note for SP4 we'll have the issue that we have clang-tools from multiple
> packages but clang-tools isn't versioned :/  The Factory/leap way would be to
> have separate sources for each llvm version in each product.  Meh.
Hmm, don't we have the same problem for existing packages like python3-clang?

> IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version}
> and the Recommends/Requires from clang/clang-devel should be
> to clang-tools >= %{version}.
I went with an unversioned package in https://build.opensuse.org/request/show/782745 because clang-tools contains mostly scripts that use the unversioned executables. If we allowed multiple packages to coexist, this would lead to a situation where e.g. git-clang-format-9 would use clang-format, which might point to clang-format-11. Patching the scripts would be non-trivial.

The package contains basically all clang files that can't coexist in multiple versions.

Also there was already a precedence with python3-clang and of course libc++.

> For the OBS solver that might be ambiguous
> but GCC solves this with Prefer: in the prjconfs.  At least this avoids
> needing to touch packages again and again.
GCC is a lot cleaner fortunately. I'm also not a big fan of using update-alternatives to provide the unversioned executables and would rather go the GCC way. (Bug 1120098, comment 1, but the maintainer at the time didn't like that.)
 
> Aaron, would you be opposed to such a change in the Factory packages?
> (I'd switch building of individual clang-tools%{_sonum} back on so SLE
> could 1:1 use the Factory packages which seems to be a requirement here)
With the changes I mentioned above this shouldn't be needed, I hope. Unless I'm missing something.

(In reply to Richard Biener from comment #10)
> I do have similar issues with libcxx and libabi of course ...
How was this solved previously? The idea of turning the builds off for old versions long precedes my stint at maintainership, it goes to back to https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm?linkrev=base&rev=478 in 2016.
Comment 12 Richard Biener 2020-12-16 08:56:37 UTC
(In reply to Aaron Puchert from comment #11)
> (In reply to Richard Biener from comment #3)
> > install check & file conflicts for x86_64]
> > 
> > found conflict of clang-tools-11.0.0-3.2.x86_64 with
> > clang7-7.0.1-3.13.1.x86_64
> >   /usr/bin/clang-format-diff
> >   /usr/bin/clang-tidy-diff
> >   /usr/bin/git-clang-format
> >   /usr/bin/run-clang-tidy
> > 
> > found conflict of clang-tools-11.0.0-3.2.x86_64 with
> > llvm7-7.0.1-3.13.1.x86_64
> >   /usr/bin/hmaptool
> > 
> > found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm9-9.0.1-3.3.1.x86_64
> >   /usr/bin/hmaptool
> 
> In Factory clang-tools has
> 
> # Some binaries used to be in the clang package.
> Conflicts:      clang5
> Conflicts:      clang6
> # hmaptool used to be contained in the llvm package.
> Conflicts:      llvm5
> Conflicts:      llvm6
> 
> So for llvm7 I'd just add them here. The hmaptool conflict with llvm9 is
> probably because Leap's llvm9 doesn't have
> https://build.opensuse.org/request/show/782745, thus clang-tools yet?

Since we keep llvm7 separate I've fixed in there by adding a conflict to
clang-tools instead.  And yes, llvm9 doesn't yet have clang-tools - I'm
still pondering to adopt this for SLE somehow.

> (In reply to Richard Biener from comment #8)
> > I have submitted a change to llvm7 to Conflict with clang-tools.  I fear we
> > cannot simply update SP2 llvm9 from Factory since that now has clang-tools
> > but does not build them (as it comes from newer llvm there) but we still
> > need it to build Mesa-drivers in SP2 (in SP2 llvm9 is the newest llvm and
> > clang9-devel requires clang-tools).
> To be honest, I don't like the artificial dependency clangX-devel's CMake
> files have on binaries. But perhaps this can be solved with
> https://build.opensuse.org/package/rdiff/devel:tools:compiler/
> llvm9?linkrev=base&rev=42, which allows any clang-tools version. Perhaps you
> also need
> https://build.opensuse.org/package/rdiff/devel:tools:compiler/
> llvm9?linkrev=base&rev=56, in case the binaries changed.
>
> > Note for SP4 we'll have the issue that we have clang-tools from multiple
> > packages but clang-tools isn't versioned :/  The Factory/leap way would be to
> > have separate sources for each llvm version in each product.  Meh.
> Hmm, don't we have the same problem for existing packages like python3-clang?

Those have appropriate conflicts with themselves and already exist for all
versions.  But yes, in Factory you'd get complaints for multiple source
packages building the same named binary package.  For the SLE SP setup
there isn't any complaint when the same binary package in different SPs comes
from different source packages - but it's a latent issue at the point a
maint update is needed ... :/
 
> > IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version}
> > and the Recommends/Requires from clang/clang-devel should be
> > to clang-tools >= %{version}.
> I went with an unversioned package in
> https://build.opensuse.org/request/show/782745 because clang-tools contains
> mostly scripts that use the unversioned executables. If we allowed multiple
> packages to coexist, this would lead to a situation where e.g.
> git-clang-format-9 would use clang-format, which might point to
> clang-format-11. Patching the scripts would be non-trivial.

Oh.  So the clang-tools package from llvm11 in SLE15 SP3 will now use
llvm7 binaries ... I'd have to look in detail into those - I wonder if
we can patch them to use the versioned binaries and/or add a version
specific bin/ dir we can point PATH to where unversioned symlinks to
the versioned binaries exist and we can adjust the scripts to use the
corresponding binaries.

That said, for SLE the current setup is probably not what users expect
(but clang-tools is on PackageHub only).  For Leap 15.3 we will have
differing 'llvm' packages I'm sure (not defaulting to llvm7 but llvm11).

> The package contains basically all clang files that can't coexist in
> multiple versions.
> 
> Also there was already a precedence with python3-clang and of course libc++.
> 
> > For the OBS solver that might be ambiguous
> > but GCC solves this with Prefer: in the prjconfs.  At least this avoids
> > needing to touch packages again and again.
> GCC is a lot cleaner fortunately. I'm also not a big fan of using
> update-alternatives to provide the unversioned executables and would rather
> go the GCC way. (Bug 1120098, comment 1, but the maintainer at the time
> didn't like that.)
>  
> > Aaron, would you be opposed to such a change in the Factory packages?
> > (I'd switch building of individual clang-tools%{_sonum} back on so SLE
> > could 1:1 use the Factory packages which seems to be a requirement here)
> With the changes I mentioned above this shouldn't be needed, I hope. Unless
> I'm missing something.

OK, I will investigate in more detail when I return from vacation.  I hope
we'll have a basic setup for Leap 15.3 at that point so we can cross-check
there as well.

> (In reply to Richard Biener from comment #10)
> > I do have similar issues with libcxx and libabi of course ...
> How was this solved previously? The idea of turning the builds off for old
> versions long precedes my stint at maintainership, it goes to back to
> https://build.opensuse.org/package/rdiff/devel:tools:compiler/
> llvm?linkrev=base&rev=478 in 2016.

The binary packages from newer SP "prevail" and we only ever had a single
source llvm package in each SP for now.  So it magically worked.  When using
the GCC scheme we'd have updated libcxx and libabi throughout whole SLE 15
to the newest available llvm.  So we didn't really solve the issue we
merely are lucky that the behavior is still deterministic.
Comment 13 Aaron Puchert 2020-12-16 11:38:23 UTC
(In reply to Richard Biener from comment #12)
> (In reply to Aaron Puchert from comment #11)
> > In Factory clang-tools has
> > 
> > # Some binaries used to be in the clang package.
> > Conflicts:      clang5
> > Conflicts:      clang6
> > # hmaptool used to be contained in the llvm package.
> > Conflicts:      llvm5
> > Conflicts:      llvm6
> > 
> > So for llvm7 I'd just add them here. The hmaptool conflict with llvm9 is
> > probably because Leap's llvm9 doesn't have
> > https://build.opensuse.org/request/show/782745, thus clang-tools yet?
> 
> Since we keep llvm7 separate I've fixed in there by adding a conflict to
> clang-tools instead.
That's what I meant, clang-tools should get conflicts on clang7 and llvm7.

> And yes, llvm9 doesn't yet have clang-tools - I'm
> still pondering to adopt this for SLE somehow.
Either you introduce it there as well or add conflicts as for {clang,llvm}{5,6,7}. Not sure what's better for SLE.

> Those have appropriate conflicts with themselves and already exist for all
> versions.  But yes, in Factory you'd get complaints for multiple source
> packages building the same named binary package.  For the SLE SP setup
> there isn't any complaint when the same binary package in different SPs comes
> from different source packages - but it's a latent issue at the point a
> maint update is needed ... :/
And I assume that dropping the package from an older source would require a maintenance update? Wasn't there also the possibility to drop built packages? But that affected only the installation medium, right?

> > > IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version}
> > > and the Recommends/Requires from clang/clang-devel should be
> > > to clang-tools >= %{version}.
> > I went with an unversioned package in
> > https://build.opensuse.org/request/show/782745 because clang-tools contains
> > mostly scripts that use the unversioned executables. If we allowed multiple
> > packages to coexist, this would lead to a situation where e.g.
> > git-clang-format-9 would use clang-format, which might point to
> > clang-format-11. Patching the scripts would be non-trivial.
> 
> Oh.  So the clang-tools package from llvm11 in SLE15 SP3 will now use
> llvm7 binaries ...
Not necessarily, because we use update-alternatives. So it depends on what is installed on the machine. It's not like GCC where the unversioned package contains fixed symlinks, rather llvm is just a stub that requires llvm7, but if a newer version is installed update-alternatives would prefer that instead.

In any event, the clang-tools scripts don't change a lot, so the version mismatch isn't really a problem. It would just be misleading if git-clang-format-X would invoke clang-format-Y instead of clang-format-X.

> I'd have to look in detail into those - I wonder if
> we can patch them to use the versioned binaries and/or add a version
> specific bin/ dir we can point PATH to where unversioned symlinks to
> the versioned binaries exist and we can adjust the scripts to use the
> corresponding binaries.
It should be possible, but we'd need a few patches and maintain them, and I'm not sure whether it's worth the effort.

> That said, for SLE the current setup is probably not what users expect
> (but clang-tools is on PackageHub only).
Hard to tell for me. It's not any core functionality - you can still compile with just clang, which also has clang-tidy and clangd. What would be in clang-tools though are scan-{build,view} to run the static analyzer, but these were in a separate package previously (clang-checker), so not much has changed, and maybe git-clang-format plus the clang-*-diff scripts.

Though clang-checker was versioned and simply conflicting with other versions of itself. But it didn't really matter which version you'd install as all of them would just use whatever update-alternatives selected as the standard clang.
Comment 14 Swamp Workflow Management 2020-12-16 14:24:39 UTC
SUSE-RU-2020:3840-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1176964,1179155
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP2 (src):    llvm7-7.0.1-3.16.1
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP1 (src):    llvm7-7.0.1-3.16.1
SUSE Linux Enterprise Module for Development Tools 15-SP2 (src):    llvm7-7.0.1-3.16.1
SUSE Linux Enterprise Module for Development Tools 15-SP1 (src):    llvm7-7.0.1-3.16.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    llvm7-7.0.1-3.16.1
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    llvm7-7.0.1-3.16.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 15 Swamp Workflow Management 2020-12-20 17:15:34 UTC
openSUSE-RU-2020:2297-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1176964,1179155
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.1 (src):    llvm7-7.0.1-lp151.2.15.1
Comment 16 Manfred Hollstein 2020-12-26 13:28:12 UTC
(In reply to Richard Biener from comment #2)
> (In reply to Aaron Puchert from comment #1)
> > (In reply to Richard Biener from comment #0)
> > > Again SLE 15 SP3 will keep llvm7 as 'llvm'
> > Isn't Mesa the only consumer of llvm in SLE?
> > 
> > But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA.
> 
> Mesa is currently the only consumer of llvm9 but there are several packages
> that use clang/llvm for building (rust for example) and those still use llvm7
> via the llvm package.

rust is especially interesting to me. I currently cannot build my various rust versions (needed to build MozillaFirefox ESR vs. Release) anymore; details can be found in <https://build.opensuse.org/package/show/home:manfred-h:devel:languages:rust:rust-1.46/rust-1.46.0> and <https://build.opensuse.org/package/show/home:manfred-h:devel:languages:rust:rust-1.47/rust-1.47.0>. Both apparently need an "llvm-devel >= 8.0"; I could enable the builtin version of LLVM as it's done for Leap <= 15.1 or various SLE versions, but as Leap 15.2 has a proper llvm-devel I'd suggest we go down that route to ensure Leap 15.3 has at least the version provided by Leap 15.2 - or even newer. In the interest to allow building of rust > 1.45, I'd appreciate a solution here. Thx!

> I'm now trying to sync up the package structure on SLE to what we have on
> Factory some more, re-syncing at least the llvm9 copy and more carefully
> llvm7.

That would be really great!
Comment 17 Aaron Puchert 2021-03-03 22:48:15 UTC
We have llvm11 in Leap 15.3 now, but the llvm metapackage is still at version 7, which is a downgrade from Leap 15.2, compare

https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm (9.0.1)
https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm (7.0.1)

That doesn't seem right. Hard to tell for me what the implications are, because I think some packages are using hardcoded LLVM versions on Leap. But there are definitely packages that BuildRequire the metapackage and I think I'll get complaints if they link to such outdated library versions.
Comment 18 Richard Biener 2021-03-04 08:11:39 UTC
(In reply to Aaron Puchert from comment #17)
> We have llvm11 in Leap 15.3 now, but the llvm metapackage is still at
> version 7, which is a downgrade from Leap 15.2, compare
> 
> https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm (9.0.1)
> https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm (7.0.1)
> 
> That doesn't seem right. Hard to tell for me what the implications are,
> because I think some packages are using hardcoded LLVM versions on Leap. But
> there are definitely packages that BuildRequire the metapackage and I think
> I'll get complaints if they link to such outdated library versions.

I guess it's the call of the release managers whether they want to replace the SLE provided llvm metapackage with one we'd fork in Leap 15.3.  I think diverting this to PackageHub is a no-go since the same packages may not exist on both SLE and PackageHub.

So - Lubos?
Comment 19 Richard Biener 2021-03-04 08:14:51 UTC
Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE
and only provide it via PackageHub.  We'd of course need to keep the "old"
'llvm' (in version 7) in the SLE build system or alternatively arrange all
packages that require llvm for building / running to use versioned requires
(and binaries).  Or divert all those packages to PackageHub as well.

Anyway, probably way too late now so forking of 'llvm' is the only realistic plan.
Comment 20 Aaron Puchert 2021-03-04 23:47:56 UTC
(In reply to Richard Biener from comment #19)
> Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE
> and only provide it via PackageHub.  We'd of course need to keep the "old"
> 'llvm' (in version 7) in the SLE build system or alternatively arrange all
> packages that require llvm for building / running to use versioned requires
> (and binaries).  Or divert all those packages to PackageHub as well.
Out of curiosity, can you run "ibs whatdependson" on the llvm metapackage in SLE? That would make it easier to understand the impact. There is probably lots of packages in Leap/Backports though, judging from the same query in Factory.
Comment 21 Richard Biener 2021-03-05 08:00:31 UTC
(In reply to Aaron Puchert from comment #20)
> (In reply to Richard Biener from comment #19)
> > Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE
> > and only provide it via PackageHub.  We'd of course need to keep the "old"
> > 'llvm' (in version 7) in the SLE build system or alternatively arrange all
> > packages that require llvm for building / running to use versioned requires
> > (and binaries).  Or divert all those packages to PackageHub as well.
> Out of curiosity, can you run "ibs whatdependson" on the llvm metapackage in
> SLE? That would make it easier to understand the impact. There is probably
> lots of packages in Leap/Backports though, judging from the same query in
> Factory.

That yields for 15:GA

   Mesa-drivers
   bcc
   beignet
   gnome-builder
   gnome-code-assistance
   libclc
   meson-testsuite
   rust

and for 15:SP1:GA

   Mesa-drivers
   bcc
   beignet
   gnome-builder
   gnome-code-assistance
   libclc
   meson-testsuite
   rust

and nothing in SP2/3 or the Update repos (seems project inheritance doesn't
work for whatdependson).  The above is for x86_64.  Since SP2 Mesa-drivers
depends on a versioned llvm version.  Oddly enough there's a bcc in SP3
as well and it depends on llvm but osc whatdependson doesn't list it.

Thus take this with a grain of salt.
Comment 22 Aaron Puchert 2021-03-07 20:30:50 UTC
(In reply to Richard Biener from comment #21)
>    Mesa-drivers
Depends on llvm11 directly now.

>    bcc
Seems to depend on llvm directly, which means it would use llvm7 in SLE/Leap. Which is probably fine, but BPF is a relatively new target, so an update is probably not a bad idea.

>    beignet
Builds with llvm7 latest anyway. Strangely Factory has a different specfile specifically asking for llvm7, but SLE still uses the metapackage. I don't see a reason to not update though.

>    gnome-builder
>    gnome-code-assistance
These are probably using libclang. I think using a newer version wouldn't hurt. If we don't, we'll have to live with Leap users having Clang 7 under the hood as well.

>    libclc
This should probably use the same LLVM version that Mesa is using. The package consists of LLVM IR files, and while the format is mostly stable I'm not sure if that's guaranteed. Package is also somewhat outdated... but not sure what the update policy is here. Though if you update Mesa, then this should be fine to update as well.

>    meson-testsuite
No idea what the test suite is doing with LLVM, but probably not so important.

>    rust
Interesting case. Rust uses the somewhat unstable LLVM API, which means it typically needs changes for every new LLVM version. So it should probably not require the metapackage but something like llvm-devel-provider < (N+1).0.0, or cmake(LLVM) < (N+1).0.0 where N is the latest supported version.
Comment 23 Aaron Puchert 2021-04-17 21:58:57 UTC
We have llvm11 in SLE 15 SP3 and thus also Leap 15.3.

I have opened bug 1184920 for getting a newer llvm metapackage into Leap 15.3 so that users don't have to suffer a downgrade there.