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.pa...@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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core