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