View Issue Details

IDProjectCategoryView StatusLast Update
0001356CentOS-4yumpublic2013-03-23 21:33
Reporterchriseh Assigned To 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionsuspended 
Product Version4.3 - x86_64 
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.

Relationships

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

Activities

kbsingh@karan.org

kbsingh@karan.org

2006-05-27 07:16

administrator   ~0003507

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

chriseh

2006-05-27 07:23

reporter   ~0003508

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?

kbsingh@karan.org

kbsingh@karan.org

2006-05-27 07:27

administrator   ~0003509

please reread my last comment.
chriseh

chriseh

2006-05-27 07:38

reporter   ~0003510

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
kbsingh@karan.org

kbsingh@karan.org

2006-05-27 07:53

administrator   ~0003511

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,
chriseh

chriseh

2006-05-28 15:53

reporter   ~0003515

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.
kbsingh@karan.org

kbsingh@karan.org

2006-05-28 16:17

administrator   ~0003516

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.
kbsingh@karan.org

kbsingh@karan.org

2006-05-28 16:17

administrator   ~0003517

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

ahuffman

2006-07-05 10:16

reporter   ~0003617

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
gushi

gushi

2006-07-14 22:18

reporter   ~0003692

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
lamont

lamont

2007-08-01 23:00

reporter   ~0005784

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

mattdm

2007-08-01 23:21

updater   ~0005786

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

JohnnyHughes

2007-08-02 13:19

administrator   ~0005794

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)

lamont

lamont

2007-08-02 17:02

reporter   ~0005798

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

JohnnyHughes

2007-08-02 21:26

administrator   ~0005804

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.

tigalch

tigalch

2013-03-23 21:33

manager   ~0016954

CentOS4 is EOL.

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