yum, and 2 packages that provide the same thing

[Michael Schwendt]

On Fri, 18 Apr 2008 13:03:33 -0600 (MDT), Stephen Warren wrote:

> On Fri, April 18, 2008 12:08 pm, Jeff Spaleta wrote:
> > On Fri, Apr 18, 2008 at 9:57 AM, Stephen Warren
> > <s-t-rhbugzilla at wwwdotorg.org> wrote:
> >>  Please bother to read my previous email where I explained why this
> >> wasn't
> >>  an appropriate solution.
> >
> > Then you'll have to live with the fact that numerics in packagenames
> > don't version compare...even if you encode numbers into them which you
> > ascribe versioning information to.
> >
> > You've fallen into an exceptional, pathelogical case that should be
> > avoided, choice which sub-optimal solution best fits your needs.
> 
> That's fine. I (personally at least) am fine with things the way they are.
> I was just hoping to be able to "dot the i's" by solving this one last
> niggling point. If there simply isn't a solution, then that's the way it
> is.
> 
> But, I do just want to point out one persistent misunderstanding that I
> think you have.

In my point of view, Jeff is just confused by your misunderstanding
of virtual provides.

You've created a case where you expect unison227 to update
unison213. That's exactly what you expect when you expect that "yum
install unison" will install the virtual "unison" pkg in unison227, which
is higher than the virtual unison pkg in unison213.

Further, the Obsoletes/Provides pair in unison213 is wrong+questionable.
You've got:

unison213
  obsoletes:
    unison < 2.27.57-3
  provides:
    unison = 2.13.16-9.fc8.3

It obsoletes *itself* because the obsoletes tag covers a much higher
version range than what is provided. The unison227 package obsoletes
the same range, so you have two packages competing with eachother here,
too. Instead, unison213 ought to obsolete at most "unison <= 2.13".

> I wasn't hoping yum would compare package names unison213 and unison227
> and pick the later one.

No, but you hoped it would compare the EVR of the virtual packages
instead and effectively treat the two packages as upgradeable, see above.