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

[richard.purdie at linuxfoundation.org]

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.

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.

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

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.

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

Cheers,

Richard