Comment # 2 on bug 1120098 from
(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.

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


You are receiving this mail because: