pidgin obsoleting itself

[Michael Schwendt]

On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:

> On Wed, 2010-06-09 at 19:23 +0200, Michael Schwendt wrote:
> > On Wed, 09 Jun 2010 13:10:10 -0400, James wrote:
> > > which is to say you have:
> > > 
> > > 1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah
> > > 
> > > 2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a
> > > single file.
> > > 
> > > 3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2
> > > (because that's what they had before).
> > > 
> > > ...if at the end of the "split" you want "yum install pkgA" to install
> > > pkgA-blah (or vice versa), then it's not _just_ a split and you probably
> > > want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the
> > > first versions). You can do this instead of the obsoletes, but I don't
> > > see the point.
> > 
> > If at the end of the split user does "yum install pkgA-blah-2", this
> > erases pkgA-1 ... unless pkgA-blah-2 strictly requires pkgA-2, which
> > is not always desired.
> 
>  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:

  1. User has pkgA-1 installed.
  2. Packager performs a split and introduces at least one new subpkg, so:
     pkgA-blah-2 and pkgA-2.
  3. User follows some documentation and runs "yum install pkgA-blah" to
     add something.
  4. Package "pkgA" is erased (obsoleted) => bug.

> To put it another way when the
> user first installed pkgA-1 they could have wanted:

Nothing else than "pkgA-1", because user cannot foresee the split
of either the package contents OR the package dependencies. Or user
simply relied on the distribution's installer to install packages.

> 1. What pkgA-2 and pkgA-blah-2 provide.
> 
> 2. What pkgA-2 provides.
> 
> 3. What pkgA-blah-2 provides.
> 
> ...but they got #1 because that was all pkgA-1 provided. Now there is a
> package split and the user can choose any of #1, #2 or #3.
>  If you only want them to be able to choose between #1 and #2 (or #1 and
> #3) then you need some kind of requires _as well_. But that's because
> you have some requirement _as well_ as just a package split.

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

All is well (including the self-Obsoletes) if sub-packages OR separate
add-on packages, which obsolete a package, also depend on that same package.
Where that isn't true, competing Obsoletes => playing with fire.
As explained.