[RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Denys Dmytriyenko]

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"

That will generate libfoo_1 and libbar_2 packages, but version 3 will be
exported in shlibs database, leading to the following versioned runtime
dependencies:

RDEPENDS: libfoo (>=3) libbar (>=3)

This fixes the problem.

Signed-off-by: Denys Dmytriyenko <denis@denix.org>

---
 classes/package.bbclass |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/classes/package.bbclass b/classes/package.bbclass
index 5a9fa50..7a0ba80 100644
--- a/classes/package.bbclass
+++ b/classes/package.bbclass
@@ -652,6 +652,10 @@ python package_do_shlibs() {
 		needs_ldconfig = False
 		bb.debug(2, "calculating shlib provides for %s" % pkg)
 
+		pkgver = bb.data.getVar('PV_' + pkg, d, 1)
+		if not pkgver:
+			pkgver = ver
+
 		needed[pkg] = []
 		sonames = list()
 		top = os.path.join(pkgdest, pkg)
@@ -696,7 +700,7 @@ python package_do_shlibs() {
 			fd.close()
 			package_stagefile(shlibs_file, d)
 			fd = open(shver_file, 'w')
-			fd.write(ver + '\n')
+			fd.write(pkgver + '\n')
 			fd.close()
 			package_stagefile(shver_file, d)
 		if needs_ldconfig and use_ldconfig:
-- 
1.6.3.3

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Phil Blundell]

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.

What's the typical use-case for this kind of thing?

p.

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Koen Kooi]

On 20-09-09 08:33, 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"
>
> That will generate libfoo_1 and libbar_2 packages, but version 3 will be
> exported in shlibs database, leading to the following versioned runtime
> dependencies:
>
> RDEPENDS: libfoo (>=3) libbar (>=3)
>
> This fixes the problem.

Normally I'd ask for a use case, but I know what you need it for :)

> Signed-off-by: Denys Dmytriyenko<denis@denix.org>

Acked-by: Koen Kooi <koen@openembedded.org>


>
> ---
>   classes/package.bbclass |    6 +++++-
>   1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/classes/package.bbclass b/classes/package.bbclass
> index 5a9fa50..7a0ba80 100644
> --- a/classes/package.bbclass
> +++ b/classes/package.bbclass
> @@ -652,6 +652,10 @@ python package_do_shlibs() {
>   		needs_ldconfig = False
>   		bb.debug(2, "calculating shlib provides for %s" % pkg)
>
> +		pkgver = bb.data.getVar('PV_' + pkg, d, 1)
> +		if not pkgver:
> +			pkgver = ver
> +
>   		needed[pkg] = []
>   		sonames = list()
>   		top = os.path.join(pkgdest, pkg)
> @@ -696,7 +700,7 @@ python package_do_shlibs() {
>   			fd.close()
>   			package_stagefile(shlibs_file, d)
>   			fd = open(shver_file, 'w')
> -			fd.write(ver + '\n')
> +			fd.write(pkgver + '\n')
>   			fd.close()
>   			package_stagefile(shver_file, d)
>   		if needs_ldconfig and use_ldconfig:

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Koen Kooi]

On 20-09-09 10:40, 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.
>
> What's the typical use-case for this kind of thing?

It's usefull for the case where you have a meta-release (e.g. 
codec-engine 2.24.01) containing itself (e.g. codec-engine), but also 
matching parts like dsplink 1.63, lpm 1.14, etc. When building the 
meta-release you'll get all the parts you need with matching versions, 
but ideally you want the subpackages to keep their PV.

Another usecase would be a big external-toolchain tarball where you want 
to keep libgcc and libc versions when importing it into OE.

regards,

Koen

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Khem Raj]

On Sat, Sep 19, 2009 at 11:33 PM, Denys Dmytriyenko <denis@denix.org> 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"
>
> That will generate libfoo_1 and libbar_2 packages, but version 3 will be
> exported in shlibs database, leading to the following versioned runtime
> dependencies:
>
> RDEPENDS: libfoo (>=3) libbar (>=3)

Can RPROVIDES fill in this void somehow.

>
> This fixes the problem.
>
> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
>
> ---
>  classes/package.bbclass |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/classes/package.bbclass b/classes/package.bbclass
> index 5a9fa50..7a0ba80 100644
> --- a/classes/package.bbclass
> +++ b/classes/package.bbclass
> @@ -652,6 +652,10 @@ python package_do_shlibs() {
>                needs_ldconfig = False
>                bb.debug(2, "calculating shlib provides for %s" % pkg)
>
> +               pkgver = bb.data.getVar('PV_' + pkg, d, 1)
> +               if not pkgver:
> +                       pkgver = ver
> +
>                needed[pkg] = []
>                sonames = list()
>                top = os.path.join(pkgdest, pkg)
> @@ -696,7 +700,7 @@ python package_do_shlibs() {
>                        fd.close()
>                        package_stagefile(shlibs_file, d)
>                        fd = open(shver_file, 'w')
> -                       fd.write(ver + '\n')
> +                       fd.write(pkgver + '\n')
>                        fd.close()
>                        package_stagefile(shver_file, d)
>                if needs_ldconfig and use_ldconfig:
> --
> 1.6.3.3
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Denys Dmytriyenko]

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

[1] http://arago-project.org/git/?p=arago.git;a=commitdiff;h=a6b686d9a5a81b55e17ef241f8c50a428639c048

-- 
Denys

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Denys Dmytriyenko]

On Sun, Sep 20, 2009 at 08:13:52AM -0700, Khem Raj wrote:
> On Sat, Sep 19, 2009 at 11:33 PM, Denys Dmytriyenko <denis@denix.org> 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"
> >
> > That will generate libfoo_1 and libbar_2 packages, but version 3 will be
> > exported in shlibs database, leading to the following versioned runtime
> > dependencies:
> >
> > RDEPENDS: libfoo (>=3) libbar (>=3)
> 
> Can RPROVIDES fill in this void somehow.

Does RPROVIDES specify versions?

-- 
Denys

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Phil Blundell]

On Sun, 2009-09-20 at 14:50 -0400, Denys Dmytriyenko wrote:
> Does RPROVIDES specify versions?

No.  Versions are fairly meaningless for virtuals since the different
providers aren't guaranteed to have synchronised versioning schemes.

p.

Re: [RFC][PATCH] package.bbclass: export subpackage individual version, if different from main

[Denys Dmytriyenko]

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