[OE-core] complex versioning scenario

Mark Hatle mark.hatle at windriver.com
Tue Mar 25 15:03:09 UTC 2014


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.

--Mark



More information about the Openembedded-core mailing list