Hi I had a concern over a fedora packaging rule.
I was discussing with a colleague about good rpm spec style and the topic of directory ownership came up. As a maintainer of multiple Fedora packages, I quoted to them a few fedora-review MUST checklist items regarding this:
[x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages.
The problem is that my colleague responded with an example of a Fedora package, "gtk-doc", that doesn't observe these rules. So I responded by creating this PR: https://src.fedoraproject.org/rpms/gtk-doc/pull-request/1
Unfortunately it seems like the problem is much more common than I thought:
$ rpm -qf /usr/lib/gcc libstdc++-devel-12.2.1-2.fc37.x86_64 gcc-12.2.1-2.fc37.x86_64 gcc-plugin-annobin-12.2.1-2.fc37.x86_64 gcc-gdb-plugin-12.2.1-2.fc37.x86_64 gcc-c++-12.2.1-2.fc37.x86_64
$ rpm -qf /usr/lib/locale filesystem-3.18-2.fc37.x86_64 glibc-langpack-en-2.36-7.fc37.x86_64 glibc-common-2.36-7.fc37.x86_64
$ rpm -qf /usr/lib/modules filesystem-3.18-2.fc37.x86_64 kernel-core-6.0.9-300.fc37.x86_64
I can't say how common this issue is, but I'm actually curious if the checklist rule about not owning directories from other packages should be a "MUST" item if it's not well followed.
Furthermore, it raises a bunch of other questions too: - Are there exceptions to this rule? (i.e. when a "conflicts" doesn't exist) - Perhaps duplicate directory ownership just a "SHOULD" while duplicate file ownership is a "MUST"? - Is there really a good reason to avoid duplicated ownership on directories in general with rpm?
Some clarity on the topic would help greatly.
Thank you!
The fedora-review tool is helpful, but its output is not always 100% correct or complete. There is quite a bit in the actual Packaging Guidelines about file and directory co-ownership. Both are allowed and common under certain conditions. I think the text there should answer your questions.
fedora-review
If there is a case that remains unclear under the linked guidelines, it’s likely that clarification would fall under the scope of the FPC.
Ok understood, thanks! I'll close this.
Metadata Update from @mystro256: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)