Directories not owned by package

[Nicolas Mailhot]

Le jeu 15/01/2004 à 11:47, Enrico Scholz a écrit :
> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes:
> 
> >> The check is not to work around package bugs in Core and to own every
> >> directory which a core package should include already
> >
> > This is a correctness thing. It came up on the list before - ideally rpm
> > should auto-own all directories a package uses
> 
> No; this will solve the clean-uninstall problem only, but can cause
> other, much more severe problems:
> 
> * when not owned, the current umask applies. With restrictive 077
>   settings, package becomes unusable for ordinary users
> * it will break symlinks; e.g. consider packages which are shipping
>   a FHS compliant /etc/init.d/A and RHL style /etc/rc.d/init.d/B
>   initscript. When ignoring directoriy ownership in the suggested
>   way, you will end in two distinct directories '/etc/init.d' and
>   '/etc/rc.d/init.d'. Later installation of chkconfig (which links
>   /etc/init.d to /etc/rc.d/init.d) can not solve this.

So what ?
If someone removes the package that creates the default symlinks do you
really think rpm will not create /etc/init.d and /etc/rc.d/init.d given
two packages that were build using this paths ?

This is not an ownership problem - this is an ordering problem. Whatever
warranties the current system gives on directory links issues it is not
related to directory ownership since rpm *will* create missing
directories so if your symlink-creation package is installed after your
symlink user-package you're dead anyway.

Sure there need to be some sort of symlink/directory permissions related
fix. But the current way of doings things do not protect you against
these errors either - things sort of work, nothing more.

Cheers,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040115/6424823c/attachment.sig>