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