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.