Red Hat Bugzilla – Bug 152691
yum resolves dependencies against wrong arch with exactarch=1
Last modified: 2014-01-21 17:51:40 EST
yum install openssl openssl-devel openssl096 fails with
IOError - # 2 - No such file or directory
stracing shows that it's looking for the openssl i686.hdr file which it has not
bothered to download even though it's present in header.info and the existing
openssl package is the i686 version.
------- Additional Comments From firstname.lastname@example.org 2004-03-26 05:42:24 ----
needinfo - yum -d 5 install
see what that tells you.
------- Additional Comments From email@example.com 2004-03-26 05:59:24 ----
Works for me.
* If openssl is not installed at all, running yum gives a traceback, because
openssl is a requirement of python:
ImportError: libssl.so.2: cannot open shared object file: No such file or directory
* If openssl is installed and yum works, I can install i686 packages fine, e.g.
"yum -y install kernel-bigmem" installs kernel-bigmem-2.4.18-3.i686.rpm
* If I rm -rf /var/cache/yum and run yum, it downloads all headers of packages
not installed already.
------- Additional Comments From firstname.lastname@example.org 2004-03-26 06:24:14 ----
Created an attachment (id=609)
bzipped yum -d 5 output
My mistake. Somehow I managed to install the i386 openssl package on this
machine even though it's an Athlon and runs i686 fine. I've been installing
updates by going to redhat's web site and downloading them from the advisory
page. I must have clicked on the wrong link.
It appears the bug is actually that yum doesn't try to upgrade the architecture
when it's downloading packages, but it does try to upgrade the architecture
when it's resolving dependencies. It should be consistent.
------- Additional Comments From email@example.com 2004-03-26 06:25:58 ----
This is in the man page. set exactarch=0 if you'd like yum to change arch on a
Keep in mind changing arch on an update CAN be very very dangerous.
------- Additional Comments From firstname.lastname@example.org 2004-03-26 06:40:05 ----
OK, but it looks like yum is not handling exactarch=1 correctly as it still
tries to resolve dependencies against the upgraded arch.
------- Additional Comments From email@example.com 2004-03-31 08:24:08 ----
BTW "yum update openssl" doesn't display this behavior.
Only "yum install openssl" does.
It looks like pkgaction.installpkgs doesn't realize that a package is already
installed unless it was installed with the bestarch. If it doesn't find (name,
bestarch) then it should just look up the name (or maybe (name, arch)?) to see
if another arch of the package is installed. If exactarch is set, it should
determine the installed arch* and update to that. If exactarch is not set, it
should update to the bestarch.
*nevral.py doesn't seem to allow this? Is the arch in nulist always the
installed arch when exactarch=1?
------- Additional Comments From firstname.lastname@example.org 2004-05-18 18:36:18 ----
Seth, can you comment here? Is this really a bug? Does this belong in Yum's
bugzilla rather than a Legacy issue?
------- Additional Comments From email@example.com 2004-05-18 18:49:05 ----
I'm not even sure this is a bug - but it's definitely not fedora legacy's problem.
close this - and if it can be replicated refile in yum bugzilla.
------- Bug moved to this database by firstname.lastname@example.org 2005-03-30 18:24 -------
This bug previously known as bug 1425 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and General component.
bzipped yum -d 5 output
Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.