Directories not owned by package
Enrico Scholz
enrico.scholz at informatik.tu-chemnitz.de
Thu Jan 15 13:15:25 UTC 2004
Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes:
>> > This is a correctness thing. It came up on the list before - ideally rpm
>> > should auto-own all directories a package uses
>>
>> * 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 ?
No, just make the removal impossible by requiring the package which owns
the directory/symlink.
> This is not an ownership problem - this is an ordering problem.
It is both. With current directory ownership, you can write
| Requires(pre,postun): /etc/init.d # for A, and
| Requires(pre,postun): /etc/rc.d/init.d # for B
With your suggested change you have to know that 'chkconfig' creates
this symlink/dir. Finding this out is obviously in this case, but what's
with e.g. /usr/share/cups/doc/, the /usr/share/doc/HTML/**/common links,
/usr/share/guile/slib, ...?
For multi-distribution packages, or 3rd party repositories it may be
impossible to find a common packagename so that correct installation
order can not be guaranted.
With directory ownership this is not a problem as shown above.
Enrico
More information about the fedora-devel-list
mailing list