On 9/14/12 11:01 AM, Richard Purdie wrote:
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 <s...@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.

RPM has internal mechanisms to tag both the filetypes and architectures as being different, unlike most of the other packaging formats which assume a package with the same name is the same.

The way to deal with this is via the mapping actions. You should be able to map from ML_PREFIX-${PN} to ${PN}.${ARCH} and of course the reverse...

How it works....

So during package generation we know the package arch is unique and just strip off the mlprefix. To do the reverse iterate over all of the available MULTILIBS, there is code in rootfs_rpm.bbclass already to do this. Then reconstruct the package name based on the multilib configuration.

--Mark


Cheers,

Richard


_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to