I'm looking at putting together a PR to update the F34 packaging for the Clang static analysis plugin clazy[1], a sourcefile checker and analysis engine in the vein of clang-analyzer, but with a specific orientation towards Qt code.
As a Clang plugin, clazy builds are tied to the specific major version of LLVM / Clang that they're built against. If Clang is updated without clazy being rebuilt, it ceases to function. That happened in F32 when LLVM was updated to version 10, but cleared up with F33 when everything was re-tooled around LLVM-11. Now in F34, the default clang is based on LLVM-12, but clazy is still built for LLVM-11, so it's once again not working. (See rhbz 1832695)[2]
This happens partly because its dependency on clang isn't versioned. Currently the clazy RPM has the following Requires set on it, among others:
libLLVM-11.so
libclang-cpp.so.11
Thanks to the clang11-libs and llvm11-libs packages, those libraries STILL EXIST in F34, which becomes the crux of the problem.
It also depends on just "clang", which is basically incorrect. Now that "clang" means clang-12, clazy won't work with "clang". (It WOULD work with the clang-11 binaries from the clang11 package, but it doesn't know to use clang-11, specifically.)
I'd like the spec file to indicate that the existing F34 clazy package depends on the clang-11.0.0 package, specifically, and that my updated spec file builds a clazy that "Requires: clang-12.0.0". (Or, really, any clang-12* package.) That way, the clang11 packages will no longer satisfy either of them, and clazy will be properly flagged as requiring a rebuild. ...But without some /usr/lib/rpm/macros.d/ file to provide the necessary version numbering, I'm not super clear on how to go about doing that.
1. Does anyone have a suggestion on how this could be done with the existing tooling?
2. Are the clang / LLVM maintainers up for creating an rpm-macros- package that defines (at least) the major version number of the current default clang, so that it could be used by plugins like clazy to create versioned dependencies?
3. Should I file a request for this in bugzilla? (...I'm going to assume the answer to this last one is yes, but I'll wait and see if someone has a clever answer to my first question before I do.)
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
