On Thu, 2018-07-26 at 14:53 +0800, Kang Kai wrote: > On 2018年07月26日 06:47, [email protected] wrote: > > There is a bigger problem though since the allarch recipe signature > > filtering doesn't change what bitbake will actually build, only how > > its > > represented in sstate and the circumstances under which it would > > rebuild it. If ca-certificates DEPENDS on openssl, it will build > > openssl whether you're targeting core-image-sato or lib32-core- > > image- > > sato. This potentially means you can end up in a situation where it > > wouldn't build lib32-openssl if nothing else in lib32-core-image- > > sato > > depended upon it more directly. > > That's why extend rdepends of allarch package with all multilib > variant. > In bitbake inner environment, make ca-certificates depends on > openssl, lib32-openssl and even libn32-openssl for qemumips64. It may > cost a little more build time(I didn't test yet), but the dependency > relationship is fixed and make sure that all multilib version > of openssl exist in 'oe-core-repo' which is used for do_rootfs. > > When build ca-certificates, both openssl and lib32-openssl will be > built. And when write package of ca-certificates, remove openssl and > lib32-openssl from RDEPENDS and keep noarch-openssl. > And make both openssl and lib32-openssl provides noarch-openssl. Then > some tweak according image multilib type could be done at then end > of do_rootfs.
Requiring that all variants of openssl build in order to build ca- certificates will have huge build time impact as it will need to build both multilib toolchains. At that point we'd probably be better either building allarch recipes twice (which I don't like), or, banning non-allarch dependencies from allarch recipes. If a recipe needs a non-allarch dependency we'd make it non-allarch. We may just have to accept the latter... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
