From: Laurentiu Palcu <laurentiu.palcu@intel.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] lib/oe/rootfs.py: fix RPM multilib issue
Date: Thu, 13 Feb 2014 10:25:26 +0200 [thread overview]
Message-ID: <20140213082526.GH10078@lpalcu-linux> (raw)
In-Reply-To: <52FBCF97.6010405@windriver.com>
Hi Mark,
On Wed, Feb 12, 2014 at 01:46:31PM -0600, Mark Hatle wrote:
> 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.
There are several rpm related multilib issues in bugzilla left hanging,
unfortunately. :|
> 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.
Apparently, the multilib test we currently have on AB is to install
lib32-connman-gnome and test the ELF class of the
/usr/bin/connman-applet binary...
>
> 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.
True, this problem should be properly fixed. This patch, however, just
restores the behavior we already used in the old bash code which people
seemed to have used for a long time now.
>
> # 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.
If these parameters (_transaction_color and _prefer_color) can be easily
set before each transaction, I suppose we could alter them accordingly,
depending on the type of packages we're going to install. Doesn't seem
very complicated, in theory...
laurentiu
>
> --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()
> >
> >
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
next prev parent reply other threads:[~2014-02-13 8:25 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
2014-02-13 8:25 ` Laurentiu Palcu [this message]
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=20140213082526.GH10078@lpalcu-linux \
--to=laurentiu.palcu@intel.com \
--cc=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