Comment # 19 on bug 1119186 from Aaron Puchert

(In reply to Wolfgang Bauer from comment #18)
> The second one should indeed make it unnecessary to require the exact same
> version as it was built against, but as I see it you still need the exact
> same versions of clang and libclang installed.
We don't actually need clang, but the builtin headers. I've thought about
whether they should not in fact be part of the libclang package, because every
package I know that uses libclang also wants these headers and I'm not sure
what you can do with libclang without them. (There isn't much you can do.)

> In practice, removing the %requires_eq again won't gain much for the user
> though (it just will avoid package rebuilds when there are minor clang
> updates), so we probably still should keep it to be on the safe side.
Not with vanilla Tumbleweed, but I find myself occasionally using updates from
devel:tools:compiler that haven't landed in Factory yet ��� then I have to tell
zypper to "break" KDevelop. It does actually break, but I can fix that by
setting KDEV_CLANG_BUILTIN_DIR. Ideally Clang would just use the major version
for the include directory (like GCC does) or create a symlink, but apparently
nobody has thought about that yet.

> Actually I can imagine a situation where it probably won't help:
> Consider clang/llvm is upgraded to 8.x. The clang and clang-devel packages
> will point to 8.x eventually, but as 7.x is still in the repos, kdevelop5
> won't get rebuilt and continues to use 7.x.
Something similar actually happened with the update to LLVM 7.0.0 ��� KDevelop
didn't properly work for about a week or two because it linked with
libLLVM.so.6 and libLLVM.so.7 at the same time. I had opened bug 1120416 for
that, which is now resolved, but it will likely appear again.

> There is no dependency on clang7 though, only clang (which pulls in clang8
> then), so the appropriate headers will be missing (if you install it fresh at
> least, when updating the installed clang7 should not get removed I hope)...
> Probably an edge case though.
Would that be solved if we package the headers with libclang or in a package
required by libclang?