If you have package with PACKAGE_ARCH = "all" then the resulting package is created by run.* scripts with different paths, *FLAGS etc even when it produces same output (ie some theme). So all packages with such PACKAGE_ARCH are rebuilt after machine switch (if the machine is ie different arch like om-gta02/nokia900). Sstate is reused when you go back to om-gta02 after building nokia900, so you have ie populate_sysroot only with as many checksums as you're building different archs, but it still makes "all" as PACKAGE_ARCH less usefull. RP said, that right fix is to introduce something like all.bbclass which excludes all variables which shouldn't change the output of such package and then checksums will be the same. There is example with gtk-theme-e17lookalike from meta-shr layer in attachment.
Created attachment 156 [details] bitbake-diffsig example with gtk-theme-e17lookalike
Current status is tracked in following branches: http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/allarch http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=jansa/allarch Last issue left is using allarch.bbclass and debian.bbclass. debian.bbclass is renaming packages for runtime so if recipe has task-fso2-compliance.bb: RDEPENDS_${PN} = "libfsotransport" it needs to know what is runtime name for libfsotransport. That's why package.bbclass is calling runtime_mapping_rename for all runtime vars in control file. runtime_mapping_rename calls oe.packagedata.read_subpkgdata in meta/lib/oe/packagedata.py and important fce is this def get_subpkgedata_fn(pkg, d): archs = bb.data.expand("${PACKAGE_ARCHS}", d).split(" ") archs.reverse() pkgdata = bb.data.expand('${TMPDIR}/pkgdata/', d) targetdir = bb.data.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/', d) bb.note("archs %s" % archs) for arch in archs: fn = pkgdata + arch + targetdir + pkg if os.path.exists(fn): bb.note("found %s" % fn) return fn bb.note("returning %s" % bb.data.expand('${PKGDATA_DIR}/runtime/%s' % pkg, d)) return bb.data.expand('${PKGDATA_DIR}/runtime/%s' % pkg, d) PACKAGE_ARCHS is different for each arch om-gta02: PACKAGE_ARCHS="all any noarch arm armv4 armv4t om_gta02" nokia900: PACKAGE_ARCHS="all any noarch arm armv4 armv4t armv5te armv6 armv7 armv7a nokia900" and file we're looking for is in tmp/pkgdata all-oe-linux all-oe-linux-gnueabi armv4t-oe-linux-gnueabi armv7a-oe-linux-gnueabi nokia900-oe-linux nokia900-oe-linux-gnueabi om_gta02-oe-linux om_gta02-oe-linux-gnueabi for libfsotransport: $ find tmp/pkgdata/ -path \*runtime\* -name libfsotransport tmp/pkgdata/armv7a-oe-linux-gnueabi/runtime/libfsotransport tmp/pkgdata/armv4t-oe-linux-gnueabi/runtime/libfsotransport Problem with allarch is, that we have correctly lost -gnueabi postfix. PACKAGE_ARCH = "all" alone had TARGET_OS = "linux-gnueabi", allarch has TARGET_OS = "linux". get_subpkgedata_fn is looking for files only with the same TARGET_OS so it cannot find libfsotransport and returns default bb.data.expand('${PKGDATA_DIR}/runtime/%s' % pkg, d) which doesn't exist and libfsotransport isn't renamed to libfsotransport0 Right fix is not so simple because imagine this scenario. 1) libfsotransport is upgraded to version 2.0 and soname changes to libfsotransport2 2) image is built for nokia900 3) task-fso2-compliance still RDEPENDS on libfsotransport0 4) someone finds that task-fso2-compliance is wrong and rebuilds it still with nokia900 machine 5) task-fso2-compliance now depends on libfsotransport2 but armv4t feeds doesn't have it (still only libfsotransport0) 6) if someone rebuilds task-fso2-compliance again it will rdepends on libfsotransport0 and break feeds for nokia900 I don't know how to fix this to be 100% correct. Publishing feeds only after all archs/machines were already build makes things better. Using allarch only for recipes which don't depend on any MACHINE_ARCH/FEED_ARCH packages is also way to go, but makes allarch usable only in few special cases. Any thoughts?
Marking task-* packages as "allarch" has never been a good idea for exactly this reason and the problem occurs without allarch as you mention, it it perhaps just more hidden. In general task-* packages end up being at least target arch specific and sometimes even machine specific. I think we just have to accept that is the case...
http://git.openembedded.net/cgit.cgi/openembedded-core/commit/?id=26e5e5feb695864b11e47e24017e254c28f14494 has some initial changes to start to address this problem.
To update on the status of this bug, we're down to 5 potentially bad allarch references in OE-Core: meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb:PACKAGE_ARCH = "all" meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb:PACKAGE_ARCH = "all" meta/recipes-extended/perl/libtimedate-perl_1.20.bb:PACKAGE_ARCH = "all" meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc:PACKAGE_ARCH = "all" meta/recipes-graphics/xorg-font/font-alias_1.0.3.bb:PACKAGE_ARCH = "all"
There are WIP patches for some of these at: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/allarch
This is now reduced to the following two recipes: meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb:PACKAGE_ARCH = "all" meta/recipes-extended/perl/libtimedate-perl_1.20.bb:PACKAGE_ARCH = "all"
Final fix merged in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d6663c342e61473937e6a5a7976324c7c07252c8