[Rpm-maint] [Suse-patch] Revert provides as obsoletes behavior

Michael Schroeder mls at suse.de
Tue May 22 10:05:44 UTC 2007


On Tue, May 22, 2007 at 11:29:13AM +0200, Florian La Roche wrote:
> this has now been deployed for a really long time, so I don't think we
> should revert this again. While I see many packages where the obsoletes
> lines match too many other packages, I am not sure if you have an
> example where this is makes "life real miserable". ??

Here's an example:

Say that there once was a package A in some old release.
A was then replaced by B (maybe a package rename), so B contains

B:
    Obsoletes: A
    Provides: A

Now there may be some alternative for B, C. C also includes the
functionality of A, so also C contains

C:
    Obsoletes: A
    Provides: A

B doesn't conflict with C, but installing C will uninstall B
and vice versa.

We experienced this for example with our java packages.

But the patch actually contains two parts:

1) make obsoletes not look at provides (see above), and
2) make implict obsolete by package name not look at provides.

In my experience 2) is much nastier than 1):

Say there are packages A and B, B provides A. If you have B installed
and then install A, B will get erased.

Some more reasoning:
Looking at provides for obsoletes is not a good idea, because
you don't know if the obsoleted package doesn't provides some
other functionality as well. Say package A provides functionality
X, Y, and Z. If you install package B that obsoletes X, you still
need A for Y and Z, so why should it get erased? So just looking
at package names is saner, because in that case the packager knows
exactly which package (and which functionalities) get obsoleted.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



More information about the Rpm-maint mailing list