Bob Taylor wrote:
On Tue, 2008-02-26 at 16:09 -0600, Johnny Hughes wrote: [snip]no ... and we have no i386 kernel ... no idea how that file got changed, but the only code to make it happen would be a pentium classic processor. C5 would just die, as there is not one. (c4 too)Would anaconda even allow C5 to install on such a class cpu?OK! Thanks Johnny. You just confirmed a bug here. Now I will, as time allows, see if I can discover why /etc/rpm/platform is incorrect. Since the file is in an rpm directory, shall I look at rpm? I promise *not* to begin another thread like this one! I'm a nice guy, really!
This file (/etc/rpm/platform) is created by anaconda on install and is NOT owned by RPM or any other package. It is USED by rpm to determine your real arch where there are possibly multiple arches (based on your processor type).
I[3,4,5,6]86 packages can coexist with each other in an i386 distro install, however you can not install an i386 package and another i[4,5,6]86 package with the same Name and Epoch-Version-Release (EVR) at the same time. On Red Hat based distros, /etc/rpm/platform is used to define the main arch where more than one (based on the processor) could be main.
Also I[3,4,5,6]86 packages can exist in an x86_64 arch install and I[3,4,5,6]86 packages can exist in an ia64 arch install. These (x86_64 and ia64) are 64bit/32bit library (aka multilib) arches. They can have lib64 and lib directories and have both an i[3,4,5,6]86 package and an x86_64 (or ia64) package installed that have the same Name and EVR.
Other examples of 32bit/64bit (multilib) arches are s390 and s390x, ppc and ppc64, and finally sparc and sparc64. In each of these you can have a 32bit (lib) and a 64bit (lib64) package of the same Name and EVR installed at the same time.
So, on x86_64, you CAN have glibc.x86_64 and glibc.i686. On sparc, you CAN have glibc.sparc and glibc.sparc64 .. but on i386 you CAN NOT have glibc.i386 and glibc.i686.
I can think of nothing that will (or should) change that file (/etc/rpm/platform) except running anaconda (the installer from a CentOS CD / DVD).
If something does modify that file it is definitely a bug. Well, if you are BUILDING files with rpmbuild then sometimes on some of the multilib arches you might want to change /etc/rpm/platform to get specific results ... but that would be a controlled process and I know of no packages that do it automatically.
Some of the links by Ross seem to indicate that unixODBC-devel might impact /etc/rpm/platform ... however the version i386 version in centos-5 does not seem to as I have installed it several times for testing and it did not change my /etc/rpm/platform.
I have looked at several i386 machines, and all of them have an /etc/rpm/platform that is created on the install date, none of them have a file that has been modified.
If we can nail down something that changed /etc/rpm/platform it would be good, as that file should never change.
Thanks, Johnny Hughes
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
