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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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?

I'm hoping this issue does not exist when that patch is applied.

Cheers,

Richard