Provides for Obsoletes

[Michael Schwendt]

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.