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()
>
>
next prev parent 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