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