[Rpm-maint] RPM Obsoletes unversioned Provides too eagerly

Michael Schroeder mls at suse.de
Mon Feb 26 17:56:11 UTC 2007


On Mon, Feb 26, 2007 at 09:51:14AM -0500, Fernando Nasser wrote:
> Accordingly to Jeff the behavior was "broken" when someone changed it to 
> dislodge packages based on virtual provides.
> 
> Using your own argument, lets either revert that change or improve it.

IMHO Jeff talked about the Name -> Provides change, i.e. that rpm
searches the provides list to obsolete packages. You talk about
something totally different: whether a single "Provides: name"
provides all versions or not.

Regarding the Name -> Provides change, there are some arguments
for and against it:

+ it makes obsoletes lookup consistent with requires and conflicts.
+ you can obsolete a "feature", i.e. you do not have to enumerate
  ever packages that implements a feature if you want to obsolete
  it.

- it surprises packagers. Say there was libOLDA a long time ago,
  which was replaced by libB. This libB obsoletes libOLDA, and
  libB also provides libOLD for compatibility. Then some
  packager creates a new libC variant by copying and changing the libB
  specfile. Now the installation of libC will remove libB.
- Packages get also obsoleted if they provide an obsolete feature
  among others. But maybe the other features aren't obsolete at all.
- The current rpm implementation also looks for Provides when
  doing the "auto-obsoletes" on the package name. I.e. package
  A provides feature B, then B is created as a package. Now if
  B is installed, A will automatically get obsoleted.

My feelings are that the Name -> Provides change is a bit too
dangerous, but I also see the need for a "Feature-obsolete".
Maybe some new syntax would have been the better way, e.g.

    Obsoletes(provides): <something>

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



More information about the Rpm-maint mailing list