From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zk223.dresearch-fe.de (zk223.dresearch-fe.de [217.92.177.116]) by mail.openembedded.org (Postfix) with ESMTP id 1FA53620B7 for ; Mon, 7 Apr 2014 12:37:07 +0000 (UTC) Received: from fensuse.internal.dresearch-fe.de (fensuse.internal.dresearch-fe.de [172.29.23.6]) by zk223.dresearch-fe.de (Postfix) with ESMTP id 1D378E0122; Mon, 7 Apr 2014 12:37:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by fensuse.internal.dresearch-fe.de (Postfix) with ESMTP id 00E6A701133; Mon, 7 Apr 2014 14:37:06 +0200 (CEST) Message-ID: <53429BF2.2050804@dresearch-fe.de> Date: Mon, 07 Apr 2014 14:37:06 +0200 From: Steffen Sledz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark Hatle , openembedded-core@lists.openembedded.org, Richard Purdie , Martin Jansa References: <5330220F.8050504@dresearch-fe.de> <1395664516.24232.56.camel@ted> <533029C5.1000406@dresearch-fe.de> <1395665593.24232.58.camel@ted> <53303FAB.5020907@dresearch-fe.de> <20140324151537.GD29998@jama> <53315AE7.1020304@dresearch-fe.de> <53319AAD.5070506@windriver.com> In-Reply-To: <53319AAD.5070506@windriver.com> X-Enigmail-Version: 1.6 Subject: Re: complex versioning scenario X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 12:37:08 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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@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