[OE-core] [PATCH 1/7] allarch: only enable allarch when multilib is not used

[Richard Purdie]

On Thu, 2019-01-17 at 11:10 -0500, Dan Dedrick wrote:
> I'm resurrecting this thread because this change negatively affects
> our use of multilib. The use case that this is fixing seems to be a a
> case that would be a better fit for multiconfig than it would
> multilib. My interpretation of the use cases of multilib and
> multiconfig is as follows and someone can correct me if this is
> wrong.

I think the problem here is there is no correct answer which will work
for everyone.

People don't expect that it would build openssl if you build lib32-curl 
and you could certainly get systems where only lib32-openssl was used
or desired.

I don't think its related to multiconfig, its just that people have
different expectations of multilib.

> Multilib allows images to be built that support multiple
> architectures on the same image. Specifically this use case is
> interesting for cases where some library or tool has to be 32-bit
> (for whatever reason might apply) but the rest of the image is 64-
> bit. For example we have a 32-bit library from a third party vendor
> and that vendor won't provide us with a 64-bit version. So we want
> the majority of our system to be 64-bit but need multilib to support
> the subset of our image that needs to be 32-bit. The result is that
> some portion of our image has to be 32-bit but whenever possible we'd
> like to be using the 64-bit packages to reduce duplicating packages
> between 32 and 64 bit.

For your usecase I can see the justification. The fact remains we had
users complaining about this behaviour too though.

> Multiconfig allows for multiple configs and seems well suited to
> cases where there are separate images for each config. So you could
> have a 32-bit image from one config and a 64-bit image from another
> config. If no image cross-contamination is required, as seems to be
> the intent of the request here, then multiconfig can ensure that
> while not reducing the usefulness of allarch. The original scenario
> seemed to follow this pattern where there is a lib32-core-image-sato
> and a core-image-sato.
> 
> In our multilib case we want the behavior from before this change. So
> in the specific use case of 'lib32-curl -> ca-certificate -> openssl'
> we actually want this. The reason behind this being the desired
> behavior is that the main architecture would certainly already
> require openssl so adding the 32-bit version would cause duplication
> and therefore increase our images size unnecessarily. In the past we
> had actually found that installing some duplicate things that
> overlapped like "/usr/bin/openssl" would cause racey behavior where
> sometimes we got the 32-bit version and others we got the 64-bit
> version.
> 
> Additionally the removal of allarch from all multilib builds also
> seem like a poor choice as multilib builds now lose all of the
> benefits that are generally available from allarch.

I never liked that side of this either, however, generically fixing the
problems reported was effectively "impossible" any other way as far as
I could see.

For your use case it should be possible to "coerce" the lib32-X allarch
recipes to prefer the "normal" architecture and get the old behaviour
back? The main cost would be buildtime of two sets of allarch recipes
but that in the scheme of things should be small...

Its a difficult situation which I can see both sides of.

Cheers,

Richard