Multilib status

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.

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.

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.

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.



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.

Cheers,

Richard