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).
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
