KDE Sub-Packaging Approach on Fedora

[Paul Howarth]

Rex Dieter wrote:
> Hugo Cisneiros wrote:
>> On Tuesday 20 June 2006 10:33, Rex Dieter wrote:
>>
>>> Jonathan Underwood wrote:
>>>
>>>> OK - I'd missed that subtelty, sorry. I suppose that's the best (most
>>>> consistent) situation that can be hoped for.
>>>
>>> Or, follow what koffice in Extras did, and use a meta-package named
>>> koffice-suite.  A nice advantage of this approach is that since the old
>>> name is no longer being used, we have the opportunity to drop all those
>>> darn Epoch's from kde packaging.
>>
>>
>> And break with upstream package name, package name that the current 
>> users are already accustomed, and kdebase and kdelibs should not be 
>> sub-packaged, so they will still have these nasty Epochs. I see no 
>> advantages here.
> 
> Not if you properly Provides/Obsoletes the old name.  Obviously, the 
> subpackaging idea doesn't extend to *all* kde packages, only for the 
> ones for which it makes sense.
> 
>> BTW, I had difficulties into installing koffice because of this 
>> reason: a simply yum install koffice didn't work. Then I installed one 
>> for one until I found out koffice-suite exists (dumb me!) :)
> 
> I consider that a bug/shortcoming of yum.  koffice-suite properly 
> Provides/Obsoletes "koffice",

Really? It Obsoletes koffice but there's no explicit Provide:

$ rpm -qp --provides koffice-suite-1.5.1-1.fc5.i386.rpm
koffice-suite = 1.5.1-1.fc5
# rpm -qp --obsoletes koffice-suite-1.5.1-1.fc5.i386.rpm
koffice <= 4:1.5.1-1.fc5
koffice-i18n < 4:1.5.1

 > but 'yum install' doesn't grok "Provides",
> only real pkgs.  ):

So how come things like "yum install libstdc++.so.5" work?

Paul.