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

Hans de Goede j.w.r.degoede at hhs.nl
Sun Oct 23 18:49:43 UTC 2005



Nicolas Mailhot wrote:
> Le dimanche 23 octobre 2005 à 14:39 +0200, Michael Schwendt a écrit :
> 
>>On Tue, 18 Oct 2005 15:22:06 -0400, Hans de Goede wrote:
>>
>>
>>>Author: jwrdegoede
>>>
>>>Update of /cvs/extras/rpms/gnumeric/FC-4
>>
>>>Log Message:
>>>own dirs /usr/share/mc/templates /usr/share/mc
>>
>>This is exaggeration. Unowned directories due to optional dependencies are
>>not worth fixing like this. This creates a situation where package
>>"gnumeric" _and_ "mc" own /usr/share/mc while it ought to be _only_ "mc"
>>which should own that directory. If "mc" is not installed, the mc files
>>included in gnumeric are useless anyway. 
> 
> 
> Then they should not be installed at all.
> 
> When a package installs files it must make bloody sure it either owns
> the directory roots these files use or depend on another package that
> does. I'm dead tired of all the phylosophic arguments that leave
> dangling directories all over the filesystem, for the sysadmin to scap
> manually later.
> 
> Limiting directory ownership has always only been a workaround made
> necessary by rpm limitations, it's not an end in itself and certainly
> not an excuse to hang files on thin air. jbj has noted long ago the
> correct thing to do would be for every package to own every single path
> it needed, if rpm could sanely support it. Note there is a *large* gray
> area between owning every path (which would overwhelm current rpm) and
> never sharing dir ownership (which would require massive package
> split-ups to avoid dangling dirs). In many cases (like there) multiple
> directory owners are preferable to package split-up. OTOH dangling dirs
> is never an acceptable solution.
> 
> 

Erm, Yes.

And now I'm really confused although I tend to agree with most things 
said by Nicolas and thus tend to keeping the changes which started this 
discussion. 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"?

Regards,

Hans





More information about the fedora-extras-list mailing list