Bob Taylor wrote:
> On Wed, 2008-02-27 at 06:29 -0600, Johnny Hughes wrote:
> > Bob Taylor wrote:
>
> [snip]
>
> > > 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 again Johnny for the info. The only non-rpm I recall installing
> was the cups *.tgs for my printer which I had to compile. :-(
I'd be interested in seeing a complete /var/log/yum.log file
and the date of the last successful yum update.
-Ross
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
