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

[Hans de Goede]

Paul Howarth wrote:
> Nicolas Mailhot wrote:
> 
>> Le lundi 24 octobre 2005 à 01:30 +0200, Michael Schwendt a écrit :
>>
>>> 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.
>>
>>
>>
>> Then have gnumeric require this dir. I don't care.
>>
>> What you can't do is:
>> 1. state this dir may be required by packages that need to stuff things
>> inside
>> 2. ergo, ownership can not be shared
>> 3. but since in gnumeric case you find it too much hassle, do not
>> actually do 1. and keep 2.. But 2. is only a good rule if you do 1. If
>> you don't do 1., I don't see why other packages would, and so 2. has no
>> base at all.
> 
> 
> Couldn't this be resolved by splitting out the files that go in 
> /usr/share/mc into a separate gnumeric-mc package, and make that 
> dependent on mc?
> 
> I have to agree with Nicolas that rules about directory ownership should 
> apply consistently, and not be ignored when it's inconvenient.
> 

Yes it could be solved this way, unfotunatly this way in the end will 
lead to a zillion subpackages for almost every package out there.

Regards,

Hans