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
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
