Comment # 3 on bug 1120098 from Aaron Puchert

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