rpms/octave/devel octave.spec,1.20,1.21

Ralf Corsepius rc040203 at freenet.de
Thu Oct 27 15:43:13 UTC 2005


On Thu, 2005-10-27 at 08:27 -0500, Quentin Spencer wrote:
> Ralf Corsepius wrote:
> 
> >On Tue, 2005-10-25 at 11:19 -0400, Quentin Spencer wrote:

> >
> >>Index: octave.spec
> >>===================================================================

> >>-Prereq:         /sbin/ldconfig
> >>+Requires:       /sbin/ldconfig /sbin/install-info /etc/ld.so.conf.d

> >Also, the dependency on the directory /etc/ld.so.conf.d is very
> >questionable and arguable.
> >
> >If you really want to depend on the directory this should be
> >Requires(pre): /etc/ld.so.conf.d
> >and may-be even
> >Requires(postun): /etc/ld.so.conf.d
> >
> >A plain "Requires: <dir>" doesn't have the effect you seem to want.
> >  
> >
> This dependency was added by the maintainer at Red Hat before I took 
> over the package, so I have no idea what the intended meaning was.
I presume, the idea was to make sure /etc/ld.so.conf.d exists, when
installing a file into this directory.

This is approach (Letting one package own the directory, let packages
owning files inside Require: the directory), is problematic when it
comes to removing multiple packages at once.

Let's assume this case:

Package A ships:
/usr/share/xyz
/usr/share/xyz/FileA

Package B ships:
/usr/share/xyz/FileB

When running
rpm -e A B
rpm doesn't assure any order these packages will be removed, so it might
happen that package A is removed before package B. In this
case /usr/share/xyz is not being removed (because it still contains
files from package B) and subsequently is being emptied when removing
package B. In this case, an unowned directory /usr/share/xyz will remain
on the file system.

In general, I'd recommend to let all packages own the directories they
install files into, but in your particular case, it might be more
feasible simply not to Require /etc/ld.so.conf.d,
because /etc/ld.so.conf.d is provided by glibc, which I consider to be
in similar position to "filesystem" (cf. to the /usr/share/mc discussion
earlier this week.)

>  I'm happy to just delete it.
ACK.

Ralf





More information about the fedora-extras-commits mailing list