View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001356||CentOS-4||yum||public||2006-05-27 06:48||2013-03-23 21:33|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Product Version||4.3 - x86_64|
|Summary||0001356: Yum installs i386 and x86_64 packages|
|Description||I did a minimal install, then tried to install cyrus-sasl (among other things) via yum. This gave me:|
Transaction Check Error: file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
The problem was the 64 bit package conflicting with the 32 bit one.
|Additional Information||[root@localhost packages]# yum list *.i386|
Setting up repositories
Reading repository metadata in from local files
audit-libs.i386 1.0.12-1.EL4 installed
bind-libs.i386 20:9.2.4-2 installed
cracklib.i386 2.7-29 installed
cracklib-dicts.i386 2.7-29 installed
cyrus-sasl.i386 2.1.19-5.EL4 installed
device-mapper.i386 1.02.02-3.0.RHEL4 installed
dmraid.i386 1.0.0.rc8-1_RHEL4_U2 installed
e2fsprogs.i386 1.35-12.3.EL4 installed
gdbm.i386 1.8.0-24 installed
glib2.i386 2.4.7-1 installed
krb5-libs.i386 1.3.4-27 installed
libselinux.i386 1.19.1-7 installed
libstdc++-devel.i386 3.4.5-2 installed
openldap.i386 2.2.13-4 installed
pam.i386 0.77-66.14 installed
zlib.i386 18.104.22.168-1.2 installed
I then did 'yum erase *.i386' which removed all these packages as well as openssl.i686.
|Tags||No tags attached.|
if you read the yum documentation you will find that you can use the arch to specificy packages to be installed, eg. yum install foo.x86_64, which will only install a given arch. So the multiple arch issue is not a bug,
w.r.t the conflict - thats something we need to check and verify.
My yum.conf has exactarch=1 in it. Yet, if I do a yum install openssl (for exanple), it will try to install the i386 version despite the fact that the x86_64 version is already installed. Having to specify x86_64 every time is a bit of a pain. Shouldn't exactarch restrict it?
|please reread my last comment.|
that was very helpful, thanks.
So you're saying that the exactarch setting in yum.conf is ignored/useless?
From yum.conf manpage:
exactarch: Either â€˜1â€™ or â€˜0â€™. Set to â€˜1â€™ to make yum update only update the architectures of packages that you have installed. ie: with this enabled yum will not install an i686 package to update an i386 package. Default is â€˜1â€™
a google search clearly shows that other folks are experiencing this conflict as well:
you seem confused between the idea of installing a package and upgrading an already installed package.
yum really does not have something to compare against when you do an install - so exactarch isnt going to help at all.
either use the "exclude=*.i386 *.i586 *.i686" line in your [main] section on /etc/yum.conf to exclude all 32bit pacakges, or use the .arch naming convention to only track one tree,
Thanks, the exclude works nicely.
Yum fetching packages across archs is really non-intuitive and I would imagine non-desireable 90% of the time. On a fresh base install of CentOS 4.3, I did a yum install cyrus-sasl, assuming that it wasn't in base (turns out it was I guess). Instead of telling me I already have it installed, it tried to install i386 packages as well as the x86_64 ones. This lead to the problem with openssl.i386 conflicting with openssl.x86_64 (which wasn't obvious that this was what was happening, it just looked like openssl was conflicting with itself, since the conflict message doesn't contain any arch info).
Perhaps it should grab current arch only unless the user specifies a different arch (so assume yum install foo<.my_arch>). I'm guessing this is the wrong forum for this request though, and that I could send it to Seth.
BTW, assuming that people who submit bugs are retarded and telling them 'please reread my last comment' isn't usually helpful. Even if you're frustrated with someone who appears to be missing the point, there are better ways to deliver this. I've been working in IT, mostly at a University for over 10 years, and I've had to bite my tongue many times and more often than not, I was very happy that I did afterward.
this isnt a customer support forum - and, my first response quite clearly pointed out using the Packagename.arch naming process.
if you feel the yum doc's are misleading, post patches to the yum development process, upstream.
|keeping this issue open, we need to check, potentially fix the openssl issue.|
Just to confirm I'm seeing this too. Here are the file conflicts when I try to install the i386 version of openssl:
file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
I'm getting the same issue on yum groupinstall "Development Tools", on the openssl install, and one manpage from the redhat-lsb, and one manpage from fontconfig.
Transaction Check Error: file /usr/share/man/man1/lsb_release.1.gz from install of redhat-lsb-3.0-8.EL conflicts with
file from package redhat-lsb-3.0-8.EL
file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package
file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package
file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package
file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package
file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package
file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7.centos4 conflicts with file from package
The larger issue here is that you can't use openssl.i686 and openssl.x86_64 libraries on the same machine since the packages have conflicts.
In an ideal world you should be able to install openssl.i686 to get:
And you should be able to also install openssl.x86_64 at the same time to get:
Then you can run either 32-bit emulated or 64-bit native apps linked against the appropriate openssl libraries. These conflicts means that you cannot do that.
(although you can probably install the 32-bit version first, then install the 64-bit version with --force to steamroller through the conflicts and it'll actually leave the system in a reasonably sane state, but at the expense of using the RPMDB correctly).
|Note that there's a (rough-edged, but functional) plugin going into the next release of yum-utils which provides the "prefer-only x86_64" behavior.|
a much better approach is to install the i686 package with "rpm --nodocs " option.
This keeps happening because it is close to impossible to get the man pages to have the same MD5 sum when they are built on a different arch and generated via tetex, sgml, etc.
(Note: if you really need both installed ... if not, yum install <package_name>.x86_64 will work too)
rpm --nodocs doesn't really help when you're using yum to install an i686 binary package on an x86_64 machine that has openssl.i686 automatically resolved as one of the dependencies.
i may force install openssl.i686 with "rpm --nodocs" out of cfengine across my whole rhel4/centos4 platform though in order to eliminate this as a future problem... still, that's a hack...
it'd be better to have openssl.i686 and openssl.x86_64 package with the openssl binary, an openssl-libs.i686 and openssl-libs.x86_64 package with the /lib and /lib64 files and no conflicts, and an openssl-docs noarch package with all the docs.
that is EXACTLY the solution that I recommended ... a <package>-docs package for any binary packages that are multi-arch. However, I don't design the spec files, I just rebuild them :D
NOTE: 99% of the time, the docs packages could even be noarch ... which would also save mirror space as the package could be identical for all arches.
|CentOS4 is EOL.|
|2006-05-27 06:48||chriseh||New Issue|
|2006-05-27 06:48||chriseh||Status||new => assigned|
|2006-05-27 07:email@example.com||Note Added: 0003507|
|2006-05-27 07:23||chriseh||Note Added: 0003508|
|2006-05-27 07:25||chriseh||Note Edited: 0003508|
|2006-05-27 07:firstname.lastname@example.org||Note Added: 0003509|
|2006-05-27 07:38||chriseh||Note Added: 0003510|
|2006-05-27 07:email@example.com||Note Added: 0003511|
|2006-05-28 15:53||chriseh||Note Added: 0003515|
|2006-05-28 16:firstname.lastname@example.org||Note Added: 0003516|
|2006-05-28 16:email@example.com||Note Added: 0003517|
|2006-07-05 10:16||ahuffman||Note Added: 0003617|
|2006-07-14 22:18||gushi||Note Added: 0003692|
|2007-08-01 23:00||lamont||Note Added: 0005784|
|2007-08-01 23:21||mattdm||Note Added: 0005786|
|2007-08-02 13:19||JohnnyHughes||Note Added: 0005794|
|2007-08-02 13:20||JohnnyHughes||Note Edited: 0005794|
|2007-08-02 17:02||lamont||Note Added: 0005798|
|2007-08-02 21:26||JohnnyHughes||Note Added: 0005804|
|2007-08-02 21:27||JohnnyHughes||Note Edited: 0005804|
|2011-10-14 20:33||toracat||Relationship added||related to 0005190|
|2013-03-23 21:33||tigalch||Note Added: 0016954|
|2013-03-23 21:33||tigalch||Status||assigned => closed|
|2013-03-23 21:33||tigalch||Resolution||open => suspended|