[OE-core] [RFC PATCH 0/2] Install rdependent of allarch package with same multilib variant of image

[richard.purdie at linuxfoundation.org]

On Thu, 2018-07-26 at 14:53 +0800, Kang Kai wrote:
> On 2018年07月26日 06:47, richard.purdie at linuxfoundation.org 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