Comment # 20 on bug 1119186 from Wolfgang Bauer

(In reply to Aaron Puchert from comment #19)
> > 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

Ok, I suppose that it is indeed a problem in that case (unless kdevelop5 would
be built against that repo).
Unfortunately, I don't see how we can really cover all cases inside the
kdevelop5 package (with the way clang is packaged currently)... If we make your
case work, it can break for others.

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

I suppose the latter should actually be "fixed" by
https://phabricator.kde.org/D17858.

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

Well, that could just as well happen without the %requires_eq, because there is
no guarantee that Mesa and kdevelop5 would be rebuilt at the same time (e.g.
kdevelop5 could get an update and being rebuilt against the newer version, but
Mesa not).
Using %requires_eq in both (or actually *all* packages that use clang/libclang)
should avoid that though I suppose... ;-)

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

Sure, if libclang(X) contains the headers itself, it's basically "guaranteed"
that they are available and in the right place.
That's probably indeed the best way to ensure this.
No idea if that is a feasible/desirable thing to do (from the clang packaging
side) though.