On 11/09/2011 11:56 AM, Andreas Petzold wrote:
But: yum complains that the i686 version of
the package is not the same version as the x86_64 package. Why that is the
case I don't know. There are a number of possible reasons (different
repositories, broken mirrors, packaging errors, ....). I guess that's a
question to Connie and Pat. I'm not sure that there is an explicit rule that
32bit and 64bit rpms have to be the same version in a multilib repo, but
that's usually what a user and yum expects.
You can disable this check in yum by using the option
--setopt=protected_multilib=false or by adding "protected_multilib=false" to
yum.conf. I don't recommend doing this, as you do seem to be a novice user of
yum and rpm.
I'd say that this article[1] is the resource I'd use to discuss the
multilib issue. The long and short of it is, if the libraries don't
match in 32 and 64 bit space, your app may or may not run and it may or
may not have special bugs which are unique to your mismatched libraries
and it may or may not garble data when it attempts to save to disk if it
feels like it.
If 32 and 64 bit don't match, behavior is at best weird and at worst
terminally broken. If you are extra lucky it will just work, but why
risk it?
Yasha,
There is something weird or strangely defined in your repos, so long as
the newer packages are signed by Scientific Linux (or any of our
personal private keys) they should be safe to install. If you don't
want to modify your repo files you could download them directly from us
and do a yum localinstall on them to get past this error. I'd
suggest fixing the repo files so that they match the SL defaults, but
its up to you.
Pat
[1] http://www.redhat.com/magazine/009jul05/features/multilib/
--
Pat Riehecky
Scientific Linux Developer
