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

[Ralf Corsepius]

On Mon, 2005-10-24 at 14:04 +0200, Michael Schwendt wrote:
> On Mon, 24 Oct 2005 13:07:02 +0200, Nicolas Mailhot wrote:
> 
> > Le lundi 24 octobre 2005 à 12:28 +0200, Michael Schwendt a écrit :
> > 
> > > Well, I prefer semantic correctness of dependencies
> > 
> > Michael, semantic correctness is worth nothing to the people who
> > actually use the packages. A working system is. Plus you can not
> > advocate correctness on the points you care about, and ignore it on the
> > points you don't.
> >
> > I'll also point out there are not so many software bits like gnumeric
> > dating from Miguel's time, so if you won't do the mc directory dep for
> > gnumeric you won't do it anywhere else, and twin ownership of this dir
> > is more than acceptable practically.
> 
> gnumeric not requiring mc _just works_. gnumeric requiring mc causes users
> to raise questions about dependency bloat.
Either these mc-plugins are plugins to mc, then these must require mc,
or these plugins ain't plugins, then they are bit-junk.

So, whatever you do, this dependency exists and if you want to make it
proper and convenient you can't avoid them.

>  gnumeric owning a directory
> which belongs to a different package, is wrong. Twin ownership of files
> or directories is wrong.  You want a _single_ package to specify file
> ownership and access privileges, regardless of whether this is a
> corner-case or not. You want RPM database queries to not return ambigous
> results. 
You are splitting hairs on a non-issue:

Whatever you do, requires will always be ambiguous. 

The key to resolve this are:
* Instead of "Require: dir", let these packages share ownership on
directories.
* Such ambiguous requires normally resolve as side effects from other
requirements.

> Nobody has commented on my /usr/share/aclocal example yet.
There exist 2 strategies:
1. All packages installing something to /usr/share/aclocal must own it.

2. No package installing something to /usr/share/acloal must own,
instead one single package owns it.

Both strategies work, if being used consistently. Things only break if
these strateges are being used inconsistently.

Right now, strategy 2 for example is being applied wrt. files below dirs
being owned by the "filesystem" rpm, while strategy 1 is being applied
to perl modules.

Ralf