[OE-core] [RFC PATCH] license: Ensure we find multilib packages also

Richard Purdie richard.purdie at linuxfoundation.org
Fri Sep 14 16:01:17 UTC 2012


On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
> On 09/13/2012 03:31 PM, Paul Eggleton wrote:
> > On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
> >> Make sure to find -package, this was causing a failure
> >> in the multi-lib build license generation during rootfs.
> >>
> >> Signed-off-by: Saul Wold <sgw at linux.intel.com>
> >> ---
> >>   meta/classes/license.bbclass |    2 +-
> >>   1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> >> index 29fe938..b29067c 100644
> >> --- a/meta/classes/license.bbclass
> >> +++ b/meta/classes/license.bbclass
> >> @@ -88,7 +88,7 @@ license_create_manifest() {
> >>   	# list of installed packages is broken for deb
> >>   	for pkg in ${INSTALLED_PKGS}; do
> >>   		# not the best way to do this but licenses are not arch dependant iirc
> >> -		filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head -1`
> >> +		filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head -1`
> >>   		pkged_pn="$(sed -n 's/^PN: //p' ${filename})"
> >>
> >>   		# exclude locale recipes
> >
> > Surely this could end up matching a the wrong file when one package name is a
> > substring of another?
> >
> I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be 
> empty when rootfs runs, that did not help, I thought about adding the 
> '-', but that would fail in the non-multilib case, how can I determine 
> what the prefix will be to get a more accurate match?

I would observe here that this probably works for ipk and multilib and
only breaks for multilib+rpm. The reason is that rpm collapses the
namespace when it creates the package list so "lib32-bash" becomes bash.
I think this might be an error in however we generate the INSTALLED_PKGS
list and we might need to revisit the rpm mechanism and ensure the
multilib prefixes get added.

Cheers,

Richard





More information about the Openembedded-core mailing list