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

[Mark Hatle]

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 <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.

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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>