Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/3] package_rpm: add architecture info in rpm spec file
Date: Wed, 14 Sep 2011 09:33:01 -0500	[thread overview]
Message-ID: <4E70BB1D.4080805@windriver.com> (raw)
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A12D81DF002@shsmsx501.ccr.corp.intel.com>

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




  reply	other threads:[~2011-09-14 14:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12  8:33 [PATCH 0/3][RFC] rpm: multilib related fixes Dongxiao Xu
2011-09-12  8:33 ` [PATCH 1/3] package_rpm: add architecture info in rpm spec file Dongxiao Xu
2011-09-12 14:51   ` Mark Hatle
2011-09-13  2:24     ` Xu, Dongxiao
2011-09-13 15:29       ` Mark Hatle
2011-09-13 15:41         ` Xu, Dongxiao
2011-09-13 15:58           ` Mark Hatle
2011-09-14  1:03             ` Xu, Dongxiao
2011-09-14 14:33               ` Mark Hatle [this message]
2011-09-12  8:34 ` [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm Dongxiao Xu
2011-09-12 14:55   ` Mark Hatle
2011-09-12 15:07     ` Xu, Dongxiao
2011-09-12 17:22       ` Mark Hatle
2011-09-13  2:39         ` Xu, Dongxiao
2011-09-13 15:24           ` Mark Hatle
2011-09-14  2:56             ` Xu, Dongxiao
2011-09-14 14:34               ` Mark Hatle
2011-09-12  8:34 ` [PATCH 3/3] multilib: install MULTILIB_PACKAGE_INSTALL Dongxiao Xu
  -- strict thread matches above, loose matches on Subject: below --
2011-09-14  6:08 [PATCH 0/3][RFC v2] rpm: multilib related fixes Dongxiao Xu
2011-09-14  6:08 ` [PATCH 1/3] package_rpm: add architecture info in rpm spec file Dongxiao Xu
2011-09-14 14:37   ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E70BB1D.4080805@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=dongxiao.xu@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox