On Sun, 9 Jul 2006 20:21:11 -0400, Jesse Keating wrote: > On Sunday 09 July 2006 20:14, Wart wrote: > > Is there any reason why I need to add the Provides: for the obsoleted > > -devel subpackage? > > For an upgrade path. People that currently have -devel package installed will > need to have it go away when they update to your new package. If your new > package Obsoletes the -devel package, the update will break if the new > package doesn't also provide crossfire-maps-devel. Not true, because the new package obsoletes the sub-package, regardless of whether it is a virtual package or not. It replaces it, and hence RPM removes it during the transaction. The "upgrade path" issues are separate ones: An "Obsoletes" does not add an automatic "Provides". Effectively, you remove a package name from the global namespace. Users, who are used to a specific package name, e.g. "yum install something" will need to search where the contents of package "something" have been moved. In case the contents of the obsolete [sub-]package are gone and cannot be found in the new packages, it would be _wrong_ to add "Provides". Example: someeditor-1.0-1 (/usr/bin/someeditor and common data files) someeditor-gui-1.0-1 (/usr/bin/someeditor-gui and requires main pkg) An upgrade removes the unfinished/hacked gui version, because no upstream developer continues working on it: someeditor-2.0-1 (Obsoletes: someeditor-gui < 2.0-1) It here would be wrong to make the package "Provides: someeditor-gui = %version-%release), since it is _not_ included. And as a second issue with upgrade paths, Yum, unless patched according to bug #190116, continues seeing old non-virtual and [meanwhile broken] sub-packages, even if there are "Obsoletes" in the new packages. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
