Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia <hongxu.jia@windriver.com>]

On 11/22/2013 08:27 PM, Richard Purdie wrote:
> On Fri, 2013-11-22 at 20:21 +0800, Hongxu Jia wrote:
>> Hi Richard,
>>
>> 1. What is the situation to set PACKAGE_ARCH = "${MACHINE_ARCH}"
>> in packagegroup recipe?
>>
>> In this case, MACHINE is qemux86-64, and the packagegroup-core-nfs's
>> RDEPENDS are:
>> "packagegroup-core-nfs-server" -> "nfs-utils" [style=dashed]
>> "packagegroup-core-nfs-server" -> "nfs-utils-client" [style=dashed]
>>
>> We check one utility in nfs-utils by invoking file:
>> $ file image/usr/sbin/exportfs
>> image/usr/sbin/exportfs: ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for
>> GNU/Linux 2.6.34, not stripped
>>
>> Should we consider the nfs-utils and lib32-nfs-utils are different
>> arch? If the answer is yes, the lib32-packagegroup-core-nfs's
>> RDEPENDS should be:
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils-client"
>> [style=dashed]
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils" [style=dashed]
>>
>> In this situation, I think we should set PACKAGE_ARCH with
>> "${MACHINE_ARCH}" in packagegroup-core-nfs recipe.
>>
>> But there are lots of packagegroup packages that didn't have set
>> PACKAGE_ARCH with "${MACHINE_ARCH}" in their recipe. After a quick
>> search in oe-core, 7 packagegroup recipes did set and almost 33 didn't,
>> so how about use PACKAGE_ARCH = "${MACHINE_ARCH}" by default for
>> packagegroup or just did not inherit allarch in packagegroup.bbclass?
>>
>> 2. What shoud we do if packagegroup packages is allarch?
>>
>> When the packagegroup packages is allarch and multilib is enabled,
>> should we still *do the multilib work* for this allarch recipe?
>> If we do, the override issue happened.
>>
>> In this case, if we don't set PACKAGE_ARCH with "${MACHINE_ARCH}",
>> packagegroup-core-nfs and lib32-packagegroup-core-nfs have different
>> ${WORKDIR}:
>>
>> WORKDIR="${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
>> MULTIMACH_TARGET_SYS="${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
>>
>> In packagegroup-core-nfs, we have:
>> TARGET_VENDOR="-poky"
>> PN="packagegroup-core-nfs"
>>
>> In lib32-packagegroup-core-nfs, after the multilib process we have:
>> TARGET_VENDOR="-pokymllib32"
>> PN="lib32-packagegroup-core-nfs"
>>
>> So we had better to forbid multilib work for the allarch recipe.
> Do you have
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26559c581695f60861483691e08eee06f524287f applied to your tree?

Yes, I have that commit on my poky/master, the issue still existed.

//Hongxu

> I'm hoping this issue does not exist when that patch is applied.
>
> Cheers,
>
> Richard
>