During the package review of qvge , the following question came up:
Are the any requirements placed on the contents of AppStream metadata,
particularly the field project_license ? It feels natural that is
MUST be the same (module differences in notation) as specfile License,
since both have the same meaning. However, I cannot find anything in
Licensing Guidelines about this.
In my experience, this comes up quite often, since upstreams often have
bundled dependencies or other copy-pasted code with different license
than upstream's own code, yet AppStream metadata, LICENSE file, README
and so only list upstream's own license.
I looked through the packaging guidelines just now to see if I could find any guidance on if it is appropriate for applications packaged in the main Fedora repos to have telemetry sent back to upstream automatically (not just crash reports, but usage telemetry of some kind), and I couldn't find anything. Has there been any decisions by FESCO/packaging committee about telemetry in apps and is it written in the policy somewhere?
I am asking because just today a new PR was made to Audacity (one of the packages I help maintain in Fedora) that adds telemetry gathering: https://github.com/audacity/audacity/pull/835. It is said to be optional and starts as disabled - but the code for reporting back will still be in the package non-the-less.
I'm looking at putting together a PR to update the F34 packaging for the
Clang static analysis plugin clazy, 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)
This happens partly because its dependency on clang isn't versioned.
Currently the clazy RPM has the following Requires set on it, among others:
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
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
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
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.)