[OE-core] Multilib status

[Mark Hatle]

On 9/16/11 4:32 AM, Richard Purdie wrote:
> Hi Mark/Dongxaio,
> 
> We really need to get the remainder of the multilib bugs wrapped up. I
> think there is some confusion about the exact approach to take to fix
> some of them so I'm hoping to try and summarise the problems here so we
> can work out some resolutions.

Let me explain where I am quickly.  I just spent two days working on reproducing
the issue(s).  So far I've not reproduced the direct failures but a series of
others.  I finally figured out part of the reason I wasn't seeing this.  I had a
typo in my configuration:

DEFAULTTUNE-virtclass-mulitlib-lib32 = "x86"

This resulted in two sets of binaries normal and lib32 that were more or less
identical in the RPM case.  We -really- need a sanity check that stupid typos
like that don't cause problems.

---

So now that I finally have a built with that done... see below.

> Problem A
> =========
> 
> We can have multiple forms of "machine specific" packages now, one for
> each multilib e.g.:
> 
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("normal")
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib64")
> task-core-x11-base-1.0-r34.qemux86_64.rpm ("lib32")
> 
> (lets assume the first uses /lib/, the second /lib64/ and the
> thrid /lib32/, an artificial example I realise)
> 
> I know one proposal was to map:
> 
> task-core-x11-base-1.0-r34.lib32_qemux86_64.rpm to
> task-core-x11-base-1.0-r34.lib32_qemux86.rpm but this isn't correct
> since the library directories are different. In this specific case it
> might not matter but in general it would. What is also important is that
> the different versions imply different dependencies. The lib64 bit
> version would pull in and select lib64 bit libs. Its these dependencies
> which are a key reason these are not "all" arch packages.
> 
> The end result is therefore we likely want:
> 
> task-core-x11-base-1.0-r34.qemux86_64.rpm
> task-core-x11-base-1.0-r34.lib64_qemux86_64.rpm
> task-core-x11-base-1.0-r34.lib32_qemux86_64.rpm
> 
> and I believe there are some patches Dongxiao has created which do this.

Yes, I'm currently testing his new MACHINE_virtclass-multilib-... patch.  So far
it seems to be working.. assuming this is the approach we go with, we'll want to
add some type of sanity check so that it's not possible to collide between the
different multilib configurations.  (Alternatively we could, for each multilib,
specify a default machine virtclass in the format you list above.

An alternative I was thinking of over night would be to avoid the RPM remapping
on the "machine" packages.. but I'm not sure if that is really a good idea.
However, it would could simplify the configuration aspects.

> Problem B
> =========
> 
> If we install task-core-x11-base-1.0-r34.qemux86_64.rpm which depends on
> "connman", how does the system figure out to associate this to mean we
> want the "x86_64" architecture packages installed?
> 
> As far as I can tell there are two proposals around:
> 
> 1) Set the architecture in the package provides and depends (a bit ugly)
> 
> 2) Configure libzypp to understand that qemux86_64 does really map to
> x86_64 architecture and imply x86_64 dependencies.
> 
> Solving problem A above is the first step towards resolving this either
> way but we don't seem to have a resolution on this second part.

Agreed.

> For reference, we really do want these task packages to have an
> associated architecture so the user can easily build up blocks of the
> system using a given ABI.

This is going to be somewhat of a problem I suspect, simply because that is not
the way RPM is/was designed.  We can adjust the rootfs install time, but this
won't address field upgrade/installs.

RPM (and Red Hat Linux/Fedora systems) appear to be designed that any package
that reasonably meets the run-time dependencies can be used.  There is a concept
of a "best" machine based on the resolver hierarchy, but ELF size may or may not
be a factor in that decision.

Doing this is quite powerful, but it also has a conscious decision set behind
it.  If "bash" is required by a script, it really doesn't matter if it's ELF32,
ELF64 or something else, as long as something provides bash.

> What I really need now is an idea of which patches you both agree on
> that we need to merge (I think we have some for problem A) and a
> resolution on problem B along with some patches so we can close this set
> of issues out.
> 
> If there are further issues can you reply to this email either with the
> details or a pointer to the specific additional problems.

Now that I have my stupid typo out of the way, I expect to have further
information in a few hours as to the regularly dependency resolution failure
Dongxiao was reporting.  (Library dependencies -are- ELF specific, so those have
to work properly!)

--Mark

> Cheers,
> 
> Richard
> 
>