- 1 File and Directory Ownership
- 1.1 The directory is wholly contained in your package, or involves core functionality of your package.
- 1.2 The package places files in many directories that are part of a larger environment's infrastructure.
- 1.3 The directory is also owned by a package implementing required functionality of your package.
- 1.4 Multiple packages own files in a common directory but none of them needs to require the others.
- 1.5 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.
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
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. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a 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.
gnucash places many files under the /usr/share/gnucash directory
gnucash package should own the
The package places files in many directories that are part of a larger environment's infrastructure.
kdeutils places files in (among other places) /usr/share/applications/kde4 /usr/share/kde4/apps /usr/share/kde4/services
Solution: the infrastructure directories above should be placed in a
kde-filesystem package, and
The directory is also owned by a package implementing required functionality of your package.
pam owns the /etc/pam.d directory gdm places files into /etc/pam.d
pam package should own the
/etc/pam.d directory, and
Multiple packages own files in a common directory but none of them needs to require the others.
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.
One common example of this is a Perl module. 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.