Red Hat Bugzilla – Bug 508907
yum.conf-manpage says $arch is replaced by python's os.uname()[4], which is not always correct
Last modified: 2014-01-21 01:13:45 EST
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): rpm-4.4.2.3-9.el5 yum-3.2.19-18.el5 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() 'ia32e' >>> os.uname()[4] 'x86_64' >>> server / # cat /etc/rpm/platform ia32e-redhat-linux 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.
anaconda in fedora 8 or 9 and beyond stopped using /etc/rpm/platform - which is why it is not mentioned in the man page.
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
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.
The specific case you're referring to ia32e vs x86_64 can be solved by NOT using $arch but using $basearch. try it out.
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.
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?
$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: baseurl=http://packages.vmware.com/tools/esx/4.0u1/rhel5/$basearch http://packages.vmware.com/tools/esx/4.0u1/rhel5/$arch 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
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.