Sorry, apparently I wasn't clear on the fact that the system does NOT have
cracklib.i686 installed at present. It is yum that is trying to install
it, along with cracklib.x6_64. This is odd. I would think that I would
only need one or the other, and in my case that would be the x86_64
version. I am wondering if anyone else has seen this behavior.
BTW, apparently this is an issue for SL6.0 only. I checked wth someone who
has SL6.1 and for them, the yum updare went smoothly.
Eve
On Fri, 13 Jan 2012, zxq9 wrote:
Date: Fri, 13 Jan 2012 12:47:20 +0900
From: zxq9 <[email protected]>
To: [email protected]
Subject: Re: cracklib dependency problem
On 01/13/2012 08:16 AM, Eve V. E. Kovacs wrote:
I am getting the following error when yum tries to do
the nightly update on an SL6 system:
Transaction Check Error:
file /usr/share/locale/hi/LC_MESSAGES/cracklib.mo conflicts between
attempted installs of cracklib-2.8.16-2.el6.i686 and
cracklib-2.8.16-4.el6.x86_64
file /usr/share/locale/zh_CN/LC_MESSAGES/cracklib.mo conflicts between
attempted installs of cracklib-2.8.16-2.el6.i686 and
cracklib-2.8.16-4.el6.x86_64
The dependencies are messed up.
Does anyone know how to resolve this?
Have you tried rebuilding your rpm database (rpm --rebuilddb)? Usually I get
pretty good luck with trying that before anything else.
The second place to look would be to see if you really need both i686 and
x86_64. If you don't have anything that depends on i686 you could safely
remove it (this is likely, but check before you do anything).
And... beyond that the cracklib package specs would need to be checked to see
why these two versions of the same package are trying to override each other
like that. These are only language translation files -- so its really not a
big deal if you let one squish the other (it is extremely likely they are
identical), but the spec should already be written that way to begin with.
Specifically, if they really are different they should be installed to
different locations, and if they are idential then they should be in a
separate common-dependency noarch package or take another route to avoid a
conflict. If this paragraph just confuses you then don't bother with specs
unless you have some time on your hands, though.
Hope this helped more than confused.
***************************************************************
Eve Kovacs
Argonne National Laboratory,
Room E-217, Bldg. 362, HEP
9700 S. Cass Ave.
Argonne, IL 60439 USA
Phone: (630)-252-6208
Fax: (630)-252-5047
email: [email protected]
***************************************************************
