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

[Kang Kai]

On 2018年07月26日 06:47, richard.purdie at linuxfoundation.org wrote:
> Hi Kai,
>
> On Thu, 2018-07-26 at 00:41 +0800, kai.kang at windriver.com wrote:
>> The series rfc patch is trying to install 64bits packages which is
>> required by allarch package to 32 bits image. Work for rpm and need
>> little more work and test for dpkg and opkg.
>>
>> Take ca-certificates as example. It requires openssl. So it intalls
>> openssl for both core-image-sato and lib32-core-image-sato. But
>> lib32-openssl is expected to be installed to lib32-core-image-sato.
>>
>> So extend rdpendent of allarch package with all multilib variants and
>> 'noarch-' as well.
>>
>> Extend
>> ca-certificates -> openssl
>>
>> to
>>
>> ca-certificates -> openssl, lib32-openssl, noarch-openssl
>>
>> Rdepends on openssl and lib32-openssl make both of them exist in
>> oe-core-repo when do rootfs. And then make both openssl and
>> lib32-openssl provide noarch-openssl. And only keep noarch-openssl in
>> RDEPENDS when write package for ca-certificates. When do image rootfs
>> for lib32-core-image-sato, remove openssl if installed already and
>> install lib32-openssl to provide noarch-openssl for allarch pacakge
>> ca-certificates.
>>
>> And extend rprovides of allarch package with prefix 'noarch-' too
>> that
>> it may be required by other allarch packages. Put all dependent
>> packages
>> of all allarch recipes in oe-core to a new ariable
>> 'ALLARCH_RDEP_PKGS'.
>>
>> Any comment for this method is welcomed. Thanks a lot.

Hi Richard,

Thanks for detailed reply.

> I think this is kind of the right direction but its not ready in this
> form. Taking a step back and thinking about this problem, its actually
> similar to the allarch recipes signature problem.
>
> Normally if A DEPENDS on B, the taskhash of A includes the taskhash of
> B. In the allarch case this is problematic so you see ca-certificates-
>> openssl listed in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.
> I think (but am not 100% sure) that everything you list in
> ALLARCH_RDEP_PKGS is already covered somewhere in
> SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.
>
> I'd therefore propose using SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS instead of
> adding a ALLARCH_RDEP_PKGS which duplicates information. I can't see
> any case where you'd want an entry in one but not the other.
Yes, it seems ALLARCH_RDEP_PKGS and I'll try to use 
SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS instead.

>
> Rather than changing the RPROVIDES/RDEPENDS in package_{deb|ipk|rpm},
> you should do this once in package.bbclass.
ok.

>
> 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.


>
> There is no easy way to solve this problem since somehow, if you're
> building lib32-<image> it needs to build lib32-openssl and if you're
> building <image> it needs to build openssl. "pushing" that information
> back up the dependency chain is very hard, we have no such mechanism.
I once want to set 'PREFERRED_PROVIDER_noarch-openssl' in image.bbclass, 
and finally find that the setting only exists
in d of <image>, and can't pass to outer context of 'defaultpkgname'

>
> I'm afraid I don't have a solution for this piece, its a very hard
> problem to solve. Your current patches happen to work as there are
> other more direct dependencies which tend to ensure the right thing
> happens but we can't rely on that and it probably isn't the case for
> all the dependencies.
>
> Finally, the package manager shouldn't really need changes for this
> approach to work. If things RPROVIDE and RDEPEND on the noarch
> versions, the feed priorities should mean the right things happen. If
> that doesn't happen automatically, the feed prorities are not working
> correctly and that needs fixing, not the 2/2 patch you're proposing. I
> suspect this issue needs fixing regardless of anything else.
Make feed repo with different priority once was an option. But I 
selected this way first. I'll work on it.

Regards,
Kai

>
> Cheers,
>
> Richard
>

-- 
Regards,
Neil | Kai Kang