[Rpm-maint] idea for new keyword: ObsoleteBy

[Mark Hatle]

I believe conflicts has been used for this purpose in the past.  While it's not 
an automatic replacement, it does alert the admin to remove the custom package, 
and replace it with the distro package that is conflicting.

--Mark

Stanislav Brabec wrote:
> Seth Vidal wrote:
> 
>>> libfoo-mybranch.spec:
>>> Version:    2.3
>>> Provides:   libfoo = %{version}
>>> ObsoleteBy: libfoo >= 2.4
>>>
>>> What do you think about such feature?
>> What does this get you that isn't already handled by 'Obsoletes'?
>>
>> If you're introducing a pkg later why not put 'Obsoletes' in it?
> 
> As an author of a private libfoo-mybranch, I don't want to modify the
> mainline libfoo package.
> 
> This concept may be usable for installation of packages from different
> sources: mainline + my addon.
> 
> Now I have no chance to terminate packages in my addon, when all
> features were upstreamed. Package manager auto-updates always tries to
> update to the latest libfoo-mybranch. I have no chance to provide an
> update, that terminates the support of libfoo-mybranch and offers users
> to upgrade to the latest mainline libfoo.
> 
> 
> Well, I have a very similar problem with Requires in openSUSE nowadays:
> 
> Mainline packages contains gnome-panel and banshee. gnome-panel does not
> require banshee.
> 
> But if I install downstream gconf2-branding-openSUSE, which adds banshee
> to the default gnome-panel configuration, then gnome-panel starts to
> require banshee. I cannot add it directly to gnome-panel (because
> mainline gnome-panel does not depend on banshee). I cannot add it to
> gconf2-branding-openSUSE (if gconf2-branding-openSUSE is installed but
> gnome-panel is not, I have to need to have banshee installed).
> 
> 
> That is why a more generic feature may be:
> 
> If this package is installed, then it adds 
> Add Requires:/Provides:/Supplements:/Recommends:/Conflicts:... to
> another package dependencies (if it exists).
>