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