Hi Richard and Mark, > -----Original Message----- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@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.pur...@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@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
