[OE-core] complex versioning scenario

[Steffen Sledz]

On 25.03.2014 16:03, Mark Hatle wrote:
> On 3/25/14, 5:31 AM, Steffen Sledz wrote:
>> On 24.03.2014 16:15, Martin Jansa wrote:
>>> On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote:
>>>> 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?
>>>
>>> SONAME header in library
>>>
>>> so if you're using debian.bbclass and change ABI then you should just increase major version in SONAME (that way your foo will rdepend on libfoo0 until it's rebuilt against newer libfoo1).
>>
>> Thanx, this was the decisive hint.
>>
>> I've increased the version in the SONAME header of the library and the result is a libfoo1 package. :)
>>
>> But now i hit the next problem. The following rootfs stage results in this error:
>>
>> ---------------> snip <-----------------
>> | Collected errors:
>> |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for app:
>> |  *    libfoo0 (>= gitr101+somehash) *
>> ---------------> snap <-----------------
>>
>> Should the new build of libfoo1 trigger a new compile of all packages with DEPENDS containing libfoo?
>>
> 
> If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes, it should have been rebuilt when the libfoo was rebuilt.

Unfortunately i can't confirm that.  :(

part of the real app recipe:
------------> snip <-------------
DEPENDS = "vala-native libdrtrace libdrhip libdrbcc jansson"
RDEPENDS_${PN} = "dropmodes"
------------> snap <-------------

part of the real resulting opkg control file for this app:
------------> snip <-------------
Depends: dropmodes, libglib-2.0-0 (>= 2.36.4), libdrhip1 (>= gitr27+42af787eb2), libjansson4 (>= 2.4), libc6 (>= 2.18)
------------> snap <-------------

I miss the runtime dependencies for libdrtrace and libdrbcc. Where are they gone?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz at 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