Comment # 18 on bug 1119186 from Wolfgang Bauer

(In reply to Aaron Puchert from comment #17)
> (In reply to Luca Beltrame from comment #15)
> > (In reply to Wolfgang Bauer from comment #14)
> > 
> > > That also means that we should probably better use "%requires_eq clang" to
> > > force the "correct" version.
> > 
> > Agreed. This is probably the best way to go.
> 
> I think with https://phabricator.kde.org/D12331 and
> https://phabricator.kde.org/D17858 in upstream this should no longer be
> necessary. The last change will be contained in the next 5.3 update or 5.4.

Yes, I'm aware of that and will keep it in mind for the next update.

But to clarify: The first one is already in 5.3.0 and obviously doesn't help
here.
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.

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