Comment # 11 on bug 1179155 from Aaron Puchert

(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.