Bug 508907

Summary: yum.conf-manpage says $arch is replaced by python's os.uname()[4], which is not always correct
Product: Red Hat Enterprise Linux 5 Reporter: Morten Werner Forsbring <werner>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: andrew.stiegmann, jsavanyo, mustafa_jamil
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-27 12:29:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Morten Werner Forsbring 2009-06-30 09:29:34 EDT
Description of problem:

We want to use $arch in a yum.conf-file to use VMware's yum-repository at packages.vmware.com, and in the manpage for yum.conf we're told that $arch is the same as Python's os.uname()[4]. This is not always correct, as yum seems to prefer rpmUtils.arch.getCanonArch() over os.uname()[4] if 'skipRpmPlatform' is not true. rpmUtils.arch.getCanonArch() uses /etc/rpm/platform to find the arch.

This means that on atleast a couple of virtual servers installed with RHEL5.3 x86_64, $arch in yum.conf are replaced with ia32e.

Version-Release number of selected component (if applicable):


How reproducible: always

Steps to Reproduce:

  server / # python
  Python 2.4.3 (#1, Sep 17 2008, 16:07:08) 
  [GCC 4.1.2 20071124 (Red Hat 4.1.2-41)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import os
  >>> from rpmUtils import arch
  >>> arch.getCanonArch()
  >>> os.uname()[4]
  server / # cat /etc/rpm/platform 
  server / #

Expected results:

  I expect yum to replace arch with x86_64 (not ia32e) or to be told about
  /etc/rpm/platform in the manpage.
Comment 1 seth vidal 2009-06-30 09:38:20 EDT
anaconda in fedora 8 or 9 and beyond stopped using /etc/rpm/platform - which is why it is not mentioned in the man page.
Comment 2 Morten Werner Forsbring 2009-06-30 09:42:46 EDT
To drop the /etc/rpm/platform you could make yum use arch.getCanonArch(skipRpmPlatform = 1). IMO this would be a much nicer fix than patching the manpage of yum.conf with the missing info on /etc/rpm/platform. :)

- Werner
Comment 3 Mustafa Jamil 2010-08-05 23:30:06 EDT
Hi.  I'm the manager of the VMware team that produces those packages.vmware.com repositories.

Is there any circumstance in which returning the os.uname() value is the wrong thing to do?  If there is no such circumstance, isn't the one-line fix suggested by the bug filer worth it to fix in an upcoming sustaining release (perhaps 5.6)?

This seems like a straightforward, low-hanging, bug for Red Hat to fix that'll prevent our shared customers from getting packages of the wrong architecture installed on their systems (and then calling Red Hat's or VMware's support).  And it'll not only benefit VMware; this will affect other ISVs as well.
Comment 4 seth vidal 2010-08-05 23:43:04 EDT
The specific case you're referring to ia32e vs x86_64 can be solved by NOT using $arch but using $basearch.

try it out.
Comment 5 James Antill 2010-08-06 12:05:00 EDT
 Mustafa, you _really_ want to work through the partner channels if this is a big deal to VMWare ... it's certainly possible that someone within RH can make this happen for 5.6, due to the partner/business case, if you really need that.
 I cannot break compatibility with /etc/rpm/platform though ... no matter how much I don't like it personally (RHEL-6 removed it by just not having that file).

 We could fix the documentation, for $arch although it's a bit "twisty". Probably better to say something like "$base is _roughly_ the same as uname()[4]. I'm not  running to mention /etc/rpm/platform directly given that it's strictly a weird legacy thing now. Some of the other munging done by CanonArch might be worth mentioning directly, but maybe not.

 Also, in general, almost everyone uses $basearch and puts all the athlon/i486/i586/i686/etc. arches in one place.
Comment 6 Mustafa Jamil 2010-08-06 14:52:53 EDT
If we can get by without code changes (as Seth suggested), and that this is the default way that most people use (as you, James, suggested), then I don't see the need to push this further.

Morten, can you please try out Seth's suggestion and confirm that it meets your needs?
Comment 7 Morten Werner Forsbring 2010-08-12 02:32:23 EDT
$basearch is normally fine, but not with packages.vmware.com because they
are using i686 and not i386 in the URL to their repository for 32 bit. :/
Please fix.

A dirty fix to be able to use the same yum.conf file for both 32 and 64 bit
RHEL6 is including URL's with both $arch and $basearch in the yum.conf file:


It would be nice if VMware would use $basearch as all others do. That is i386 for 32 bit and x86_64 for 64 bit in their repository URL's (a symlink named i386
linking to i686 would be very nice, and will hopefully not need any codechanges for VMware).

- Werner
Comment 8 Andrew Stiegmann 2010-08-24 13:55:24 EDT
Hi Morten,
   I have made the requested change in the VMware repositories.  We now have an i386 symlink that points to the i686 directory.  Thank you for bringing this to our attention.

   -Andrew S.