From Fedora Project Wiki
(save first version so the $@&@&@&$&@!@$##@ wiki doesn't eat it AGAIN)
 
No edit summary
Line 3: Line 3:
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 <code>filesystem</code> or <code>man</code> 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.
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 <code>filesystem</code> or <code>man</code> 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. Examples of this are:
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. Here are examples that describe how to handle most cases of directory ownership.


1) 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.
=== The directory is wholly contained in your package, or involves core functionality of your package. ===
 
An example:
<pre>
gnucash places many file under the /usr/share/gnucash directory
</pre>
 
Solution: the <code>gnucash</code> package should own the <code>/usr/share/gnucash</code> directory
 
=== The directory is also owned by a package implementing required functionality of your package. ===
 
An example:
 
<pre>
pam owns the /etc/pam.d directory
gdm places files into /etc/pam.d
</pre>
 
Solution: the <code>pam</code> package should own the <code>/etc/pam.d</code> directory, and <code>gdm</code> should <code>Require:</code> the <code>pam</code> package
 
=== The directory is also owned by a package implementing optional functionality of your package. ===
 
An example:
 
<pre>
bash-completion owns the /etc/bash_completion.d directory
git places files into /etc/bash_completion.d
</pre>
 
Solution: Both packages should own the <code>/etc/bash_completion.d</code> directory, as bash-completion is optional functionality and the installation of git 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.
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.


2) Multiple packages have files in a common directory but none of them requires others.
=== Multiple packages have files in a common directory but none of them requires others. ===


An example:
An example:
Line 16: Line 47:
Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama
</pre>
</pre>
Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory.
Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory.
 
Solution: In this case, each package must own the <code>/usr/share/Foo/Animal/</code> directory.


In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details.
In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details. Note that when co-owning directories, you <b>must</b> ensure that the ownership and permissions on the directory match in all packages that own it.

Revision as of 15:45, 2 September 2009

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. 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. 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 file 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

Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package

The directory is also owned by a package implementing optional functionality of your package.

An example:

bash-completion owns the /etc/bash_completion.d directory
git places files into /etc/bash_completion.d

Solution: Both packages should own the /etc/bash_completion.d directory, as bash-completion is optional functionality and the installation of git 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.

Multiple packages have files in a common directory but none of them requires others.

An example:

Foo-Animal-Emu puts files into /usr/share/Foo/Animal/Emu
Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama

Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory.

Solution: In this case, each package must own the /usr/share/Foo/Animal/ directory.

In all cases we are guarding against unowned directories being present on a system. Please see Packaging:UnownedDirectories for the details. Note that when co-owning directories, you must ensure that the ownership and permissions on the directory match in all packages that own it.