Bug 508907 - yum.conf-manpage says $arch is replaced by python's os.uname()[4], which is not always correct
yum.conf-manpage says $arch is replaced by python's os.uname()[4], which is n...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: James Antill
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2009-06-30 09:29 EDT by Morten Werner Forsbring
Modified: 2014-01-21 01:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-27 12:29:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.