2017-05-24 09:50 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001356CentOS-4yumpublic2013-03-23 21:33
Reporterchriseh 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionsuspended 
Product Version4.3 - x86_64 
Target VersionFixed in Version 
Summary0001356: Yum installs i386 and x86_64 packages
DescriptionI 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
Installed Packages
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 1.2.1.2-1.2 installed

I then did 'yum erase *.i386' which removed all these packages as well as openssl.i686.
TagsNo tags attached.
Attached Files

-Relationships
related to 0005190acknowledgedkbsingh@karan.org CentOS-5 File conflicts between i386 and x86_64 versions of libgcj package 
+Relationships

-Notes

~0003507

kbsingh@karan.org (administrator)

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.

~0003508

chriseh (reporter)

Last edited: 2006-05-27 07:25

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?

~0003509

kbsingh@karan.org (administrator)

please reread my last comment.

~0003510

chriseh (reporter)

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:

http://www.centos.org/modules/newbb/viewtopic.php?topic_id=4108&forum=28

~0003511

kbsingh@karan.org (administrator)

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,

~0003515

chriseh (reporter)

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.

~0003516

kbsingh@karan.org (administrator)

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.

~0003517

kbsingh@karan.org (administrator)

keeping this issue open, we need to check, potentially fix the openssl issue.

~0003617

ahuffman (reporter)

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

~0003692

gushi (reporter)

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
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
  file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7.centos4 conflicts with file from package
fontconfig-2.2.3-7

~0005784

lamont (reporter)

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:

/lib/libcrypto.so.0.9.7a
/lib/libssl.so.0.9.7a

And you should be able to also install openssl.x86_64 at the same time to get:

/lib64/libcrypto.so.0.9.7a
/lib64/libssl.so.0.9.7a

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).

~0005786

mattdm (updater)

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.

~0005794

JohnnyHughes (administrator)

Last edited: 2007-08-02 13:20

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)

~0005798

lamont (reporter)

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.

~0005804

JohnnyHughes (administrator)

Last edited: 2007-08-02 21:27

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.

~0016954

tigalch (manager)

CentOS4 is EOL.
+Notes

-Issue History
Date Modified Username Field Change
2006-05-27 06:48 chriseh New Issue
2006-05-27 06:48 chriseh Status new => assigned
2006-05-27 07:16 kbsingh@karan.org 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:27 kbsingh@karan.org Note Added: 0003509
2006-05-27 07:38 chriseh Note Added: 0003510
2006-05-27 07:53 kbsingh@karan.org Note Added: 0003511
2006-05-28 15:53 chriseh Note Added: 0003515
2006-05-28 16:17 kbsingh@karan.org Note Added: 0003516
2006-05-28 16:17 kbsingh@karan.org 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
+Issue History