On Sun, Sep 20, 2009 at 02:49:26PM -0400, Denys Dmytriyenko wrote: > On Sun, Sep 20, 2009 at 09:40:22AM +0100, Phil Blundell wrote: > > On Sun, 2009-09-20 at 02:33 -0400, Denys Dmytriyenko wrote: > > > Fixes the wrong versioned runtime dependency for shlib subpackages with > > > own versions. Consider this: > > > > > > PACKAGES = "libfoo libbar" > > > PV_libfoo = "1" > > > PV_libbar = "2" > > > PV = "3" > > > > Is this even legitimate usage? I had always thought that PV applied to > > the recipe, not to the output subpackages. > > PV_<pkg> works as is, because it is handled by the same code that does > FILES_<pkg>, DESCRIPTION_<pkg>, RDEPENDS_<pkg>, RPROVIDES_<pkg>, PKG_<pkg> > etc. And generated subpackages receive own versions just fine. > But for shared libraries in subpackages it has this small issue of exporting > the main PV in shlibs/pkgdata/runtime... > > > What's the typical use-case for this kind of thing? > > As Koen said, helpful for large meta-packages. In the case of external > toolchain, the main package may have version like "2009q1", while different > subpackages can get their own versions, like "2.8" for libc, "4.3.3" for > libstdc++ etc. Slightly convoluted example at [1] > W/o this fix I was getting runtime dependencies for libc >= 2009q1, instead > of 2.8
Would there be more comments, ACKs or NACKs from anyone? Is it Ok to push? -- Denys _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
