Re: complex versioning scenario

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
> On 24.03.2014 13:35, Richard Purdie wrote:
> > On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
> >> We've a complex versioning scenario here which leads me to my limits. :(
> >>
> >> There are two recipes. One for a shared library and one for an application using this library.
> >>
> >> Both use GNU autotools (so they have internal version information). For continuous integration purposes both use AUTOREV.
> >>
> >> At the moment the recipes look like this:
> >>
> >>
> >> ------------ libfoo_git.bb -------------
> >> PR = "r7"
> >> PE = "2"
> >> SRCREV="${AUTOREV}"
> >> PV = "gitr${SRCPV}"
> >> ...
> >>
> >>
> >> ------------ app_git.bb ----------------
> >> DEPENDS = "... libfoo ..."
> >> PR = "r10"
> >> PE = "1"
> >> SRCREV="${AUTOREV}"
> >> PV = "gitr${SRCPV}"
> >> ...
> >>
> >>
> >> Now we have the following problem. libfoo has some incompatible
> >> changes in its interface (a new internal major version).
> >>
> >> In my opinion this should find its represenation in the package
> >> versioning in a way that the dependency checker can guarantee that the
> >> library and the application package match each other.
> > 
> > It is generally impossible to directly compare two git hashes and decide
> > whether one is "greater" than the other. This is why most git recipes
> > have PV = "0.0+git${SRCPV}" so that you can change 0.0 when something
> > major changes. That way you can put a constraint in the second recipe.
> > 
> > This is a fundamental problem with git versioning and not something we
> > can fix generically.
> 
> To have an order in the git based versions we use the PRSERV method. This works well.
> 
> But this does not help here. The change in the library interface leads
> directly to a new version of the library package itself (e.g. from
> libfoo0_gitr100+somehash to libfoo0_gitr101+someotherhash). But i need
> something i can write into the DEPENDS list of the application. :(
> 
> Steffen
> 
> BTW: Where comes the 0 in libfoo0 from?

debian.bbclass (debian package naming) which I believe in turn is
derived from the actual library version.

Its a class specific implementation so you can't depend on it in version
information though.

I still think your only solution here is to inject a real version into
PV...

Cheers,

Richard