http://bugzilla.opensuse.org/show_bug.cgi?id=1120098 http://bugzilla.opensuse.org/show_bug.cgi?id=1120098#c1 --- Comment #1 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- My proposal would be to replace clang-*.0 by clang-*, since the minor version should always be 0. (http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html) Further, I'd propose to abandon update-alternatives and directly use the metapackage version, so /usr/bin/clang from package clang version 7 points to /usr/bin/clang-7 directly. I don't think that update-alternatives provides any benefits when the we actually choose the version via metapackage. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1120098 http://bugzilla.opensuse.org/show_bug.cgi?id=1120098#c3 --- Comment #3 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Michal Srb from comment #2)

(In reply to Aaron Puchert from comment #1)

...

My proposal would be to replace clang-*.0 by clang-*, since the minor version should always be 0. (http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html)

This would make sense, but I don't want to break anything depending on the full version. I will add the clang-X -> clang-X.Y.Z to fix the references from the cmake files.

I understand that the minor version symlink was introduced with bug 1012260 and it was certainly reasonable at the time. The last 4 versions (4.0 - 7.0) of LLVM were according to the new versioning scheme, so I'm not sure if that reasoning still applies. The upstream build doesn't create this link, so I'm not sure how someone needing clang-*.0 would handle other distributions. But removing clang-*.0 is clearly not the main issue here, so I'm fine either way.

...

Further, I'd propose to abandon update-alternatives and directly use the metapackage version, so /usr/bin/clang from package clang version 7 points to /usr/bin/clang-7 directly. I don't think that update-alternatives provides any benefits when the we actually choose the version via metapackage.

Well, the metapackage is there mainly to select the newest llvm as build dependency for packages that build against it. The end users are free to install any llvm version(s) directly without the metapackage and the update-alternatives are then useful to select the version of llvm/clang tools to use. As long as it doesn't cause any issues, I prefer to keep it.

To my understanding, this is what the gcc package does as well. If I only install gcc-8, I'm not getting /usr/bin/gcc, only /usr/bin/gcc-8. With update-alternatives, it would be possible to have a different /usr/bin/clang than distro packages are built with, and that might be a problem. (Not many packages are built with Clang though.) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1120098 http://bugzilla.opensuse.org/show_bug.cgi?id=1120098#c7 Wolfgang Bauer <wbauer@tmo.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wbauer@tmo.at --- Comment #7 from Wolfgang Bauer <wbauer@tmo.at> --- (In reply to Aaron Puchert from comment #0)

CMake Error at /usr/lib64/cmake/clang/ClangTargets.cmake:296 (message): The imported target "clang" references the file

"/usr/bin/clang-7"

but this file does not exist. Possible reasons include: [...]

This problem still exists in Leap 15.1 it seems, see bug#1138457. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1120098 http://bugzilla.opensuse.org/show_bug.cgi?id=1120098#c8 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel+factory@suse.de, | |mpluskal@suse.com --- Comment #8 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Wolfgang Bauer from comment #7)

This problem still exists in Leap 15.1 it seems, see bug#1138457.

I believe that llvm7 is considered a base package in Leap and thus comes from SLE instead of Factory, so I can't port the fix back myself. I believe that someone at SUSE must first update SUSE:SLE-15-SP1:GA/llvm7 and then send this to openSUSE:Leap:15.1:Update. Or something like that. Adding some people to CC who should know better than me. -- You are receiving this mail because: You are on the CC list for the bug.