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 devel mailing list