having yum dependency conflicts on centos 5.5 with 32bit vs 64 bit
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
having yum dependency conflicts on centos 5.5 with 32bit vs 64 bit
Hi, I am the first to admmit that I am a newbie, but with the help of google i can usually muddle my way through... not this time...
While I was ill recently , I had a friend admin my server for me.. I am still not quite sure what he has done, but now when i try to install anything it has a hissy fit.
looking in bash history i see he remove fail2ban and reinstalled, but on the remove it took out a few packages...
I was getting errors eg PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/mhash.so' - /usr/lib/php/modules/mhash.so: cannot open shared object file: No such file or directory in Unknown on line
I tried to reinstall mhash, but it stated it was now deprecated and libmhash was its replacement.
libmhash installed ok, but error still occurs, and when checking there is still not any mhash.so in the dir as the error says...
I gave up on that error for the moment, when i tried to reinstall the some of the missing packages, eg libtiff as I then got the errors,
file /usr/bin/bmp2tiff from install of libtiff-3.8.2-7.el5_5.5.x86_64 conflicts with file from package libtiff-3.8.2-7.el5_5.5.i386
/usr/bin/wrjpgcom from install of libjpeg-6b-37.x86_64 conflicts with file from package libjpeg-6b-37.i386
file /usr/bin/gtk-demo from install of gtk2-2.10.4-21.el5_5.6.x86_64 conflicts with file from package gtk2-2.10.4-21.el5_5.6.i386
file /usr/bin/gtk-update-icon-cache from install of gtk2-2.10.4-21.el5_5.6.x86_64 conflicts with file from package gtk2-2.10.4-21.el5_5.6.i386
and many more lines reading similar, for dozens of different packages....
and that was just one package out of a massive list stating same error...
[root@vps01 ~]# locate libc.so.6
/lib/libc.so.6
/lib/i686/nosegneg/libc.so.6
/lib64/libc.so.6
so...
[root@vps01 ~]# yum install glibc
Package glibc-2.5-49.el5_5.7.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package glibc.i686 0:2.5-49.el5_5.7 set to be updated
---
Transaction Check Error:
package glibc-2.5-49.el5_5.7.i686 is already installed
file /sbin/ldconfig from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
file /sbin/sln from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
file /usr/sbin/iconvconfig from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
Here is the fedora policy (from a mailing list):
____________________________
Fedora, on certain architectures, supports multible binary ABIs.
This includes support for i386 on x86_64, and ppc64 on ppc.
Fedora supports these ABIs through a process called 'multi-arch'
or 'multilib', wherein the corresponding RPM packages for the secondary
arch are included along with their primary arch counterparts. These
packages are built via the same process as the primary arch packages,
and are identical to the packages that would be shipped in a
release where that arch would be the primary arch.
The primary function of multilib support in Fedora is to provide a
runtime environment for applications to use. To satisfy this, packages
that provide runtime libraries are included for the secondary arch.
The secondary function of multilib support in Fedora is to provide
a development environment. To satisfy this, packages that provide
development headers are included for the secondary arch. However,
it should be noted that it is preferred to use a full system of
the appropriate architecture to do development where possible; this
can be done by using the 'mock' package to create an appropriate
chroot.
Multilib packages are intentionally not provided for system daemons
(for example, to run alternate-wordsize versions of Apache or
PostgreSQL.) If you need to run a non-default wordsize of a system
daemon, it is recommended that you install the system with a release
that supports that architecture as the primary architecture.
Not all packages produced by a particular source RPM are included as
multilib packages; only subpackages that implement runtime libraries
or development environments are included.
Whether or not multilib packages are installed by default is controlled by
the 'multilib_policy' configuration file parameter for yum. The default
value for Fedora of 'best' installs only packages for the primary
architecture. If this is changed to 'all' packages for all compatible
architectures will be installed by default. Note that this can only be
changed post-install; anaconda uses the default of only installing packages
for the primary arch.
You can still at any time install packages for a particular arch by passing
the architecture directly to yum. For example, running 'yum install
glibc.i686', or putting 'glibc.i686' in a kickstart %packages stanza, will
install the 32-bit x86 version of glibc.
When installed in parallel, multilib RPM packages may contain files that
live in common paths. When this happens, RPM uses the following algorithm:
- If the file in both packages is identical, installation is allowed
and the file is written
- If the file in both packages is an ELF binary, the file used is the
file in the package for the primary architecture
- If the file in both packages is not an ELF binary a RPM conflict is
raised
Hi,
Thanks for that info... I already know that 32bit and 64 bit should happily coexist.. however for dome resason on my server they aren't..
tried the "32 bit choice install" as suggested in your post..
yum install glibc.i686 ,, still resulted in:
Transaction Check Error:
package glibc-2.5-49.el5_5.7.i686 is already installed
file /sbin/ldconfig from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
file /sbin/sln from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
file /usr/sbin/iconvconfig from install of glibc-2.5-49.el5_5.7.i686 conflicts with file from package glibc-2.5-49.el5_5.7.x86_64
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.