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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
