[OE-core] Multilib status

[Xu, Dongxiao]

Hi Richard and Mark,

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> Sent: Friday, September 16, 2011 5:32 PM
> To: Mark Hatle
> Cc: Xu, Dongxiao; openembedded-core
> Subject: Multilib status
> 
> 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.

In our current rootfs_rpm logic, we don't use zypper tool to make the file system, what we use is pure rpm plus db.
I am not sure whether the rpm database or sat-solver has such kind of bindings between different repo folders? (like qemux86_64 and x86_64)

Thanks,
Dongxiao

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