| Summary: | sstate should exclude more variables for packages with PACKAGE_ARCH = "all" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Martin Jansa <Martin.Jansa> | ||||
| Component: | meta-yocto | Assignee: | Richard Purdie <richard.purdie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | dvhart, poky.bs.watcher, poky.watcher, sgw | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.2 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | Final patch out for review on mailing list | ||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | --- | |||||
| Attachments: |
|
||||||
|
Description
Martin Jansa
2011-05-17 00:55:56 UTC
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" |