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

[Mark Hatle]

On 7/26/18 4:07 AM, richard.purdie at linuxfoundation.org wrote:
> 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...

allarch requiring (runtime) dependencies on non-allarch might just have to be
banned.  I hadn't considered that -- but it would resolve most of the problems
that are being worked on.

If we can produce the allarch package -once- w/o rdepends on anything then they
should still be fine.. since the dependency would be:

arch1 |
      | -> allarch
arch2 |

Avoiding conflicts and preserving the approach we want.

--Mark

> Cheers,
> 
> Richard
>