Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] lib/oe/rootfs.py: fix RPM multilib issue
Date: Wed, 12 Feb 2014 13:46:31 -0600	[thread overview]
Message-ID: <52FBCF97.6010405@windriver.com> (raw)
In-Reply-To: <cc9a8b3a006120ba793051f1a790c3cb3681c28e.1392230968.git.laurentiu.palcu@intel.com>

On 2/12/14, 12:54 PM, Laurentiu Palcu wrote:
> For some odd reason (at least I couldn't find an explanation to this,
> yet), if a multilib version of a package is installed after the main one
> (that is: in a different smart session), the main package binaries are
> not overwritten.

For two packages with the same name, but different architectures -- the non-ELF 
files must be identical (or different file names in each package.)

The ELF files are identified by type and there is a resolution mechanism within 
RPM to determine which is the 'preferred' version.

We do NOT have the resolution mechanism set, so the first package installed 
'wins'.  So if you do two packages in two separate transactions, the first 
version installed will be kept.  If you do it in one transaction, then I believe 
it ends up being the last version [or maybe it's random due to sort order?]

There is a Yocto Project defect to configure the RPM multilib settings, but so 
far it's just sat there, as nobody has either needed it -- or cared enough to 
implement it.  The reality is installed two packages with the same /bin, /sbin 
binaries is rare these days.. it's much more useful to install the libraries.

The code you have below may turn out to be a performance improvement.. (each 
smart/rpm transaction takes setup and cleanup time, so multiple transactions are 
slower then one larger transaction.)  But it's likely not fixing the actual 
problem you have.

#       The default transaction color. This value is a set of bits to
#       determine file and dependency affinity for this arch.
#               0       uncolored (i.e. use only arch as install hint)
#               1       Elf32 permitted
#               2       Elf64 permitted
#               4       MIPS reserved
%_transaction_color     3

(4 BTW is MIPS64 - n32)

_transaction_color of 3 indicates we allow Elf32 and Elf64 to be installed..

There is a second item:

_prefer_color that is used to define which item should be installed when there 
is that ELF conflict.  The numbers above follow there as well.  By default I 
believe it sets itself to '2' when doing a single transaction installed, 
preferring Elf64.

--Mark

> This commit restores the functionality to the original one, before
> migrating to python: feed all the packages to smart, apart from attempt
> only ones which are installed separately.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>   meta/lib/oe/rootfs.py |   16 ++++++++++++----
>   1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index b6baf77..9162e52 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -317,10 +317,18 @@ class RpmRootfs(Rootfs):
>
>           self.pm.update()
>
> -        for pkg_type in self.install_order:
> -            if pkg_type in pkgs_to_install:
> -                self.pm.install(pkgs_to_install[pkg_type],
> -                                [False, True][pkg_type == "aop"])
> +        pkgs = []
> +        pkgs_attempt = []
> +        for pkg_type in pkgs_to_install:
> +            if pkg_type == Manifest.PKG_TYPE_ATTEMPT_ONLY:
> +                pkgs_attempt = pkgs_to_install[pkg_type]
> +                continue
> +
> +            pkgs += pkgs_to_install[pkg_type]
> +
> +        self.pm.install(pkgs)
> +
> +        self.pm.install(pkgs_attempt, True)
>
>           self.pm.install_complementary()
>
>



  reply	other threads:[~2014-02-12 19:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12 18:54 [PATCH 0/1] lib/oe/rootfs.py: fix RPM multilib issue Laurentiu Palcu
2014-02-12 18:54 ` [PATCH 1/1] " Laurentiu Palcu
2014-02-12 19:46   ` Mark Hatle [this message]
2014-02-13  8:25     ` Laurentiu Palcu
2014-02-13 11:32   ` Richard Purdie
2014-02-13 11:50     ` Laurentiu Palcu

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=52FBCF97.6010405@windriver.com \
    --to=mark.hatle@windriver.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