pidgin obsoleting itself

[Michael Schwendt]

On Wed, 09 Jun 2010 18:00:15 -0400, James wrote:

> On Wed, 2010-06-09 at 21:38 +0200, Michael Schwendt wrote:
> > On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:
> > >  And if the user never has pkgA-1 installed, and does "install
> > > pkgA-blah" then that's all they'll get.
> > 
> > If you modify the scenario, we will talk past eachother.
> > The scenario is:
> 
>  I didn't.

http://poelcat.wordpress.com/2010/04/28/monty-python-does-the-fedora-development-list/

> >   1. User has pkgA-1 installed.

>  Ok, so, as I said before...
> 
> 1. User has nothing installed.

We can stop here already. Let's meet somewhere in the middle. Your case is
_another_ valid scenario, but it disregards the simple fact that the
package split leads to an install operation erasing an already installed
package and thus crippling/damaging the installation depending on what
gets removed. As it _may be_ possible in some cases to fix the package
dependencies and avoid such a scenario, I just say that playing with
Obsoletes bears risks.

>  Now you might argue that there are packages, for _both_ our examples,
> where the user really does want pkgA as well (and it's not a strict
> requirement).
>  We may get suggests eventually, but this has nothing to do with
> Obsoletes.

In general, only the "Obsoletes" lead to erasing an installed package,
which is the dangerous part about introducing too many Obsoletes in
packages or sub-packages.  [We've escaped from the times when Provides
also replaced packages.]

> > That isn't what I refer to. For some splits you don't have a requirement.
> > See e.g. a real-world example, where installing/adding a Nagios plugin
> > package removed Nagios because of competing Obsoletes:
> > https://bugzilla.redhat.com/590709#c13
> 
>  This example is a little more convoluted, esp. as F-12 doesn't have
> -common before and -common always had it (and should thus. have used a
> "Conflicts: nagios < 3.2.1-2" in nagios-common).

That ticket is just one example of "Obsoletes" having lead to packaging
bugs. First, a package split lead to erasing an installed package during a
normal _update_ scenario. Then followed attempts at fixing up the
packages with competing Obsoletes for a specific _install_ scenario,
which also didn't work out, because of missing strict dependencies due to
how the split is done.