[OE-core] Multilib status

[Xu, Dongxiao]

Hi Richard and Mark,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Xu, Dongxiao
> Sent: Friday, September 16, 2011 8:01 PM
> To: Richard Purdie; Mark Hatle
> Cc: openembedded-core
> Subject: Re: [OE-core] Multilib status
> 
> 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)

I updated my branch at:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/ml4

Patch 1/3 is to solve the Problem B by approach 1) that Richard mentioned.
Patch 2/3 is to solve the Problem A which defines a new architecture (lib32_qemux86_64) when PACKAGE_ARCH == MACHINE_ARCH.
Patch 3/3 is to install MULTILIB_IMAGE_INSTALL packages into final image.

Thanks,
Dongxiao

> 
> 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
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core