http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c11 --- Comment #11 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (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.
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 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++. 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.
-- You are receiving this mail because: You are on the CC list for the bug.