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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core