http://bugzilla.opensuse.org/show_bug.cgi?id=1119186 http://bugzilla.opensuse.org/show_bug.cgi?id=1119186#c20 --- Comment #20 from Wolfgang Bauer <wbauer@tmo.at> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.