KDE Sub-Packaging Approach on Fedora

[Rex Dieter]

Paul Howarth wrote:

> 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?

OK, maybe not as bad a bug in yum afterall.  

IMO, koffice-suite should Provides: koffice as well

I *do* know that if a real pkg 'foo-1' exists, but a another package 'bar-2'
includes
Provides: foo = 2
that 'yum install' foo will pull in foo-1.

-- Rex

-- Rex