我有一个64位的红帽企业Linux服务器（版本6.3），不想让我安装glibc.i686模块的32位兼容性。 当我尝试yum install glibc.i686作为根，它给了我这样一个错误的长串：
Transaction Check Error: file /lib/libc.so.6 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64 file /lib/libm.so.6 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64 file /lib/libpthread.so.0 from install of glibc-2.12-1.80.el6_3.6.i686 conflicts with file from package libc6-6:2.15-1.x86_64
下面是glibc和libc6的rpm -qa grepping的输出：
# rpm -qa | grep glibc glibc-common-2.12-1.80.el6_3.6.x86_64 glibc-2.12-1.80.el6_3.6.x86_64 # rpm -qa | grep libc6 libc6-2.15-1.x86_64
尽pipe我尽了最大的努力，Google并没有产生任何有用的帮助。
为什么这两个软件包冲突，我怎么让他们一起玩好？
编辑：
这是yum repolist的输出：
# yum repolist Loaded plugins: product-id, rhnplugin, subscription-manager Updating certificate-based repositories. Unable to read consumer identity repo id repo name status rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) 8,824 repolist: 8,824
红帽企业版Linux中没有libc6软件包。 相同文件的软件包名称是glibc 。 看起来，有人在你的服务器上安装了一个不同的Linux发行版的软件包，并且超越了他们试图这样做的错误（与你在这里看到的几乎一样）。
这当然会使您的RPM数据库相对于实际安装的软件处于不一致的状态，并可能导致兼容性和相关性问题，例如您今天遇到的问题。 例如，不再可能从受支持的存储库更新软件包，并且难以确切地确定在系统上运行的代码。
我最好的猜测是，有人（真的不知道这样做的正确方法）是否试图将glibc升级到红帽提供的版本之外，最有可能利用在版本中不存在的新functionglibc EL6附带。
正确的方法是，如果你真的需要glibc这个迟到的版本，那么就是采用Red Hat的源代码RPM，调整spec文件和任何补丁来构build新版本的glibc，并使用新版本的新二进制RPM。 然后，您自己负责维护，可能会失去供应商支持等，所以如果业务需求绝对需要，您应该只考虑这一点。 （既然你失去了你的支持，那么你最好转换成CentOS …）