File and Directory Ownership
Your package should own all of the files that are installed as part of the %install process. Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the filesystem
or man
package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.
Directory ownership is a little more complex than file ownership. Packages must own all directories they put files in, except for:
- any directories owned by the
filesystem
,man
, or other explicitly created-filesystem
packages - any directories owned by other packages in your package's natural dependency chain
In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory.
In all cases we are guarding against unowned directories being present on a system. Please see Packaging:UnownedDirectories for the details.
Here are examples that describe how to handle most cases of directory ownership.
The directory is wholly contained in your package, or involves core functionality of your package.
An example:
gnucash places many files under the /usr/share/gnucash directory
Solution: the gnucash
package should own the /usr/share/gnucash
directory
The directory is also owned by a package implementing required functionality of your package.
An example:
pam owns the /etc/pam.d directory gdm places files into /etc/pam.d gdm depends on pam to function normally, and would Require: pam (either implicitly or explicitly) separate from the directory ownership.
Solution: the pam
package should own the /etc/pam.d
directory, and gdm
should Require:
the pam
package.
The directory is owned by a package which is not required for your package to function.
Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly.
An example:
gtk-doc owns the /usr/share/gtk-doc/ directory evolution puts files into /usr/share/gtk-doc/ evolution does not need gtk-doc in order to function properly. Nothing in evolution's dependency chain owns /usr/share/gtk-doc/
Solution: the evolution
package should own the /usr/share/gtk-doc
directory. There is no need to add an explicit Requires on gtk-doc solely for the directory ownership.
As an exception, it may be preferable for such directories to be owned by an "artificial filesystem" package, such as mozilla-filesystem
. These packages are designed to be explicitly required when other packages store files in their directories, thus, in such situations, these packages should explicitly Require the artificial filesystem package and not multiply own those directories. Packagers should consider the number of affected directories and packages when determining whether to create artificial filesystem packages, and use their own best judgement to determine if this is necessary or not.
Another example:
bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself. git places files into /etc/bash_completion.d bzr places files into /etc/bash_completion.d
Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion.
The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version.
An example involving Perl modules:
Assume perl-A-B
depends on perl-A
and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.
The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the perl-A
package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A. So the perl-A-B
package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.