rpms/gnumeric/FC-4 gnumeric.spec,1.3,1.4

[Michael Schwendt]

On Sun, 23 Oct 2005 22:40:50 +0200, Nicolas Mailhot wrote:

> Le dimanche 23 octobre 2005 à 20:49 +0200, Hans de Goede a écrit :
> >  Also the "This also makes file/path based
> > dependencies impossible, since for any package which would want to
> > "Requires: /usr/share/mc" a dep resolver would run into an ambiguity."
> > Argument made by Michael is IMHO a pure theoretical and thus not valid 
> > argument, why would a package ever want todo a thing like "Requires: 
> > /usr/share/mc"?
> 
> Indeed. If one really wanted to require mc without specifying any
> package name, /usr/bin/mc would be the thing to ask for.

No, indeed not. What you call a purely theoretical dependency is "one
package requiring the root directory of something else". No more, no
less.

For instance, in order to store plugins in a plugin directory. Or to
extend a collection of something located in a directory tree. Whether or
not you could do "Requires: packagename" or "Requires: virtualname"
instead is not the point of discussion. Whether file/path based
dependencies are not used as much as they could, is not RPM's fault. The
capability is available.  I can do "Requires: /etc/rc.d" or "Requires:
/var/www/cgi-bin" if I want to ensure that such a directory is present
because my package uses it. Beep Media Player could do "Requires:
/usr/share/xmms/Skins" without caring whether the skins are in the
XMMS main package, a sub-package or wherever else.

And with regard to orphaned directories after removing packages,
RPM still doesn't do full erasure sorting, does it?