Re: complex versioning scenario

[Steffen Sledz <sledz@dresearch-fe.de>]

On 24.03.2014 13:53, Richard Purdie wrote:
> 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.

But where does it come from? A bb variable?

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

I tried this:

change libfoo recipe to PV = "1.0+gitr${SRCPV}"
leads to libfoo0_1.0+gitr102+someotherhash....ipk

then

change app recipe to DEPENDS = "... libfoo-1.0 ..."
leads to: "ERROR: Nothing PROVIDES 'libfoo-1.0'" :(

change app recipe to DEPENDS = "... libfoo0-1.0 ..."
leads to: "ERROR: Nothing PROVIDES 'libfoo0-1.0'" :(

change app recipe to DEPENDS = "... libfoo0_1.0 ..."
leads to: "ERROR: Nothing PROVIDES 'libfoo0_1.0'" :(

Where's the mistake?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058