[oe] [RFC] Version sorting in BitBake

[Denys Dmytriyenko]

On Fri, Oct 09, 2009 at 10:03:29AM +0100, Richard Purdie wrote:
> On Tue, 2009-10-06 at 12:23 -0300, Otavio Salvador wrote:
> > Hello Denys,
> > 
> > On Tue, Oct 6, 2009 at 12:46 AM, Denys Dmytriyenko <denis at denix.org> wrote:
> > [...]
> > > PV1 = "2.6.29-${PR}+gitr${SRCREV}"
> > > PV2 = "2.6.29+2.6.30-rc5-${PR}+gitr${SRCREV}"
> > > PV3 = "2.6.30-${PR}+gitr${SRCREV}"
> > >
> > > That still works with opkg, as ipkg-compare-versions sorts above PVs as
> > > expected - PV1 < PV2 < PV3
> > >
> > > But BitBake now has this flaw and sorts like this: PV2 < PV1 < PV3
> > [...]
> > 
> > Please send the patch for people to review and would be nice to have
> > it commited since many of us could have been using non-required
> > overrides.
> > 
> > Thanks by founding and _fixing_ it :-D
> 
> This worries me quite a bit as it means bitbake's version comparison
> function is broken. Is there a python version comparison function
> somewhere else we can compare bitbake's with to make sure there aren't
> any other glitches we have?

I was consulting with the ipkg-utils ipkg-compare-versions.c

> Bitbake's and opkg's version handling is meant to model Debian for
> reference.

We discussed this matter on irc with Phil/pb couple days ago. The agreement 
was that fixing BitBake to adhere to dpkg/opkg (i.e. Debian) version sorting 
rules is a good thing. The remaining question was with rpm, which, according 
to sorting algorithm docs on the Net, does not take into account any 
separators at all.

Phil was suggesting that the sorting algorithm can be adjusted runtime 
depending on the distro or whether debian.bbclass is inherited...
Any preferences of what to do with rpm?

-- 
Denys