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@xxxxxxxxxxxxx> 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. I wasn't hoping yum would compare package names unison213 and unison227 and pick the later one. Rather, I was hoping that since I'd asked to install "unison", and 2 packages both had virtual provides for "unison" with differing version numbers, then yum would pick the package with the higher version number for that virtual provide, solely based on the virtual provide version values. Please note that in the virtual provide for "unison", there are no funny version numbers encoded into the package name part; both provides are just "unison", with versions 2.13.xxxx and 2.27.xxxx. I'd consider the current situation identical to there being two packages named "foo" and "bar", each virtual providing "baz", one proving baz==1, the other baz==2. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
