Packaging/Review Guidelines change

Michael Schwendt bugs.michael at gmx.net
Fri Jan 6 12:59:39 UTC 2006


On Fri, 06 Jan 2006 12:02:18 +0100, Enrico Scholz wrote:

> bugs.michael at gmx.net (Michael Schwendt) writes:
> 
> >> The only exception case is where two packages use the same directory
> >> structure (outside of the FHS), but neither relies on the other one
> >> (aka, either one could be installed first, or without the other). Then,
> >> and only then, its acceptable for both packages to own the directory,
> >> as they both have the potential to be "first". This is a corner case,
> >> though.
> >
> > The order, in which the two are installed, is irrelevant.
> 
> I am not sure whether your statement is related to the cited paragraph. But
> generally, the order of package installation IS relevant regarding directory
> ownership.
> 
> E.g. let's have two packages A and B with
> 
> A
> | /etc/init.d/foo   (file)
> 
> B
> | /etc/init.d/ -> rc.d/init.d   (symlink)
> | /etc/rc.d/init.d/             (directory)
> 
> 
> Then, you have to make sure that 'B' is installed, before 'A' places its
> files. Else, you will end with two distinct initrd directories.

That is a special case, where a real dependency exists. 'A' _requires_ (!)
the filesystem structure provided by 'B'. That is a race between a symlink
and a directory and not just the problem of an "unowned directory".

On the contrary, the common case of "unowned directories" is when 'A'
stores optional (!) files in a directory and 'B' also stores files in that
directory. Both don't need these files at run-time, because else they
would be broken (restrictive umask at install-time leading to inaccessible
directories and so on -- if they needed access to the files, directory and
file ownership and access privileges _must_ be complete). But another
package, 'C', may complete the filesystem structure and provide means to
access the optional files contained within 'A' and 'B'. E.g. a help system
browser. That is a common case where packagers tend towards owning every
directory, even if it leads to ugly things like sharing directory
ownership between multiple packages. And then the fun starts, when rpm -qf
reports that multiple packages own directories like /usr/share/aclocal,
and one of them can mess up the access privileges by accident.




More information about the fedora-extras-list mailing list