[OE-core] [PATCH 1/3] package_rpm: add architecture info in rpm spec file

Mark Hatle mark.hatle at windriver.com
Wed Sep 14 14:33:01 UTC 2011


On 9/13/11 8:03 PM, Xu, Dongxiao wrote:
> Hi Mark,
> 

...trimming the thread a bit...

>>>>>> This patch is incorrect.  Architectural information should not be
>>>>>> in the dependencies within RPM packages.
>>>>>>
>>>>>> RPM is expected to find the proper version of a package to install
>>>>>> based on the existing dependency information.  I'm in the process
>>>>>> of investigating why certain items are not found properly.
>>>>>

> Let me take another case as an example during my debugging to this issue.
> 
> Thinking that you have built out an base qemux86-64 image, and several lib32 multilib packages. Due to the wrong selection when doing RPM, we have several packages (like libgtk), which need x86-64 version installed, however they are replace by 32bit packages. The do_rootfs process succeeded, but when booting the image, some Xserver programs fail to find /usr/lib64/libgtk.so, because in the system only /usr/lib/libgtk.so is installed, which caused the X start failure.

That is a completely different issue.  If applications need the 64-bit libraries
and the 32-bit ones are fulfilling the dependencies, then we have a dependency
mismatch.  Libraries should contain dependency information (within RPM) that
properly describe the ELF ABI as an artifact of the dependency generation.  This
is a defect we should be able to resolve in the package_rpm.bbclass.

I'll attempt to look into it today, unless someone beats me to it.

>>
>> There are different strategies we can use to deal with these situations.
>>
>> 1) Resolve the "base" non-multilib system "first", then augment it with the
>> multilib components.  This results in a "base system" + alternative packages.
>>
>> 2) Resolve the system as whole, including multilibs, and use the policy
>> components to determine the "best match".  (best match may not be working
>> right
>> today)  This results in a system based purely on dependency matches.
>>
>> Either way, our current implementation doesn't quite match either of them.
>> We're closer to the second version of the implementation today....
>>
>> If the base system approach is what we want, vs the pure dependency based
>> system, then we will need to change the way the dependencies are being
>> resolved and the ordering of the resolution in the packages_rpm.bbclass (or
>> rootfs_rpm.bbclass).  Basically:
>>
>> *) take the list of dependencies and filter out any multilibs, and only scan them
>> against the base archs.
>>
>> *) add to that resolution any multilib components that had been filtered out
>> and scan against the all archs.
>>
>> ....
>>
>> *) install as we do today
> 
> I ever tried the second approach to fix the problem, however it failed.
> 
> I split the installation into two parts as you mentioned, first part is to install the base arch packages, and it does succeed. The second part is to install resolution to multilib components, when calculating the dependency, we will find "package xxx is already installed" error will be detected again by the "justdb" installation. I think there are wrong RPM dependency when installing lib32 multilib packages. showed as follows:
> 
> Processing locale-base-en-us...
> Processing locale-base-en-gb...
> Processing task-core-boot...
> Processing task-core-apps-console...
> Processing task-core-ssh-dropbear...
> Processing task-core-apps-x11-pimlico...
> Processing task-core-x11-sato...
> Processing zypper...
> Processing task-core-x11-base...
> Processing task-core-apps-x11-games...
> Processing task-core-apps-x11-core...
> Processing task-base-extended...
> Processing rpm...
> Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install.manifest
> Preparing...                ##################################################
> libc6                       ##################################################
> update-rc.d-dbg             ##################################################
> gst-meta-audio              ##################################################
> pciutils-ids                ##################################################
> ...
> ...
> Processing lib32-connman-gnome...
> Processing lib32-task-base-3g...
> Processing lib32-task-base-wifi...
> Processing lib32-task-base-bluetooth...
> Manifest: /distro/dongxiao/build-ml6/tmp/work/qemux86_64-poky-linux/core-image-sato-1.0-r0/rootfs/install/install_multilib.manifest
> Preparing...                ##################################################
> error: Install/Erase problems:
>         package libc6-2.13-r14+svnr14157.x86_64 is already installed
>         package update-rc.d-dbg-0.7-r4.all is already installed
>         package gst-meta-audio-0.10-r10.x86_64 is already installed
>         package pciutils-ids-3.1.7-r2.x86_64 is already installed
>         package udev-extraconf-0.0-r1.x86_64 is already installed
> ...

This is a bit strange.  It should have detected from the resolution code that
the item was already installed and doesn't need to be re-installed -- unless the
above ELF types are causing this issue as well as the one described above.

--Mark





More information about the Openembedded-core mailing list