Bug 152691

Summary: yum resolves dependencies against wrong arch with exactarch=1
Product: [Retired] Fedora Legacy Reporter: John Dalbec <jpdalbec>
Component: GeneralAssignee: Fedora Legacy Bugs <bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecified   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description David Lawrence 2005-03-30 23:24:09 UTC
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 skvidal@phy.duke.edu 2004-03-26 05:42:24 ----

needinfo - yum -d 5 install 
see what that tells you.


------- Additional Comments From bugs.michael@gmx.net 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 jpdalbec@ysu.edu 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 skvidal@phy.duke.edu 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
package updates.

Keep in mind changing arch on an update CAN be very very dangerous.

------- Additional Comments From jpdalbec@ysu.edu 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 jpdalbec@ysu.edu 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 jkeating@j2solutions.net 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 skvidal@phy.duke.edu 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 dkl@redhat.com 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.