#2948 Concerns over directory ownership in packages
Closed: Accepted by mystro256. Opened by mystro256.

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.

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)

Metadata