Description of problem: Trying to install both arches (ppc and ppc64) of glibc to an OpenVZ container running F8 under ppc64. yum says it installs both version, but there is no ppc64 version in rpmdb after that. Version-Release number of selected component (if applicable): [root@rpm-build-ppc64-f8 packages]# rpm -q yum yum-3.2.7-1.fc8 [root@rpm-build-ppc64-f8 packages]# rpm -V yum S.5....T c /etc/yum.conf [root@rpm-build-ppc64-f8 packages]# cat /etc/yum.conf [main] cachedir=/var/cache/yum keepcache=1 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d How reproducible: Always Steps to Reproduce: 1. Have a F8 system running on ppc64. 2. Remove glibc from the RPMDB only: # rpm -e --justdb --nodeps glibc 3. Check there is no glibc package(s) in rpmdb: # rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' | grep glibc- glibc-common-2.7-2.ppc glibc-headers-2.7-2.ppc 4. Try to install glibc: # yum install glibc Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package glibc.ppc 0:2.7-2 set to be updated ---> Package glibc.ppc64 0:2.7-2 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: glibc ppc 2.7-2 fedora 7.7 M glibc ppc64 2.7-2 fedora 7.4 M Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 15 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: glibc ######################### [1/1] Installed: glibc.ppc 0:2.7-2 glibc.ppc64 0:2.7-2 (see it said it installed both ppc and ppc64 packages) Actual results: # rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' | grep glibc- glibc-common-2.7-2.ppc glibc-headers-2.7-2.ppc glibc-2.7-2.ppc Expected results: # rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' | grep glibc- glibc-common-2.7-2.ppc glibc-headers-2.7-2.ppc glibc-2.7-2.ppc glibc-2.7-2.ppc64 Additional info: I have also tried this, with the same results: # yum install glibc.ppc glibc.ppc64
OK, I retried that with RPM and this is what I got: # rpm -e --justdb --nodeps glibc # rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' | grep glibc- glibc-common-2.7-2.ppc glibc-headers-2.7-2.ppc # ls -l glibc-2.7-2.ppc*; rpm -ihv glibc-2.7-2.ppc* -rw-r--r-- 1 root root 8027838 Oct 27 00:13 glibc-2.7-2.ppc.rpm -rw-r--r-- 1 root root 7737750 Oct 27 00:13 glibc-2.7-2.ppc64.rpm Preparing... ########################################### [100%] file /sbin/ldconfig conflicts between attempted installs of glibc-2.7-2 and glibc-2.7-2 file /sbin/sln conflicts between attempted installs of glibc-2.7-2 and glibc-2.7-2 file /usr/sbin/iconvconfig conflicts between attempted installs of glibc-2.7-2 and glibc-2.7-2 So the first question is: why there are two conflicting packages residing in the same repository? The second question is: I see a bug in yum (it says it installed something but in fact it has not) and a bug in repository (or maybe glibc packaging). Should those be separate bugs?
Same happens with yum-3.2.8-2.fc8 -- says it installed both arches, but there is no ppc64 in rpm -q output after.
What does the following command output on your system: rpm --eval "%{_transaction_color}"
What does the following command output on your system: rpm --eval "%{_transaction_color}"(In reply to comment #3) > What does the following command output on your system: > rpm --eval "%{_transaction_color}" # rpm --eval "%{_transaction_color}" 0
I have also checked the issue on another container running F7 -- it's all the same.
Right, that's the deal with conflicts and all: the system isn't set up for multilib at all. This should deal with it: echo "%_transaction_color 3" >> /etc/rpm/macros
(In reply to comment #6) > echo "%_transaction_color 3" >> /etc/rpm/macros You made my day! It's working as expected now (in both F7 and F8). So the questions are (1) why it's not default (say, can be set in /usr/lib/rpm/ppc64-linux/macros)? (2) can yum check that and complain, instead of pretending it does the right thing? OR, probably, this is just a hack around bad repository/glibc packaging, and those binaries from glibc (/sbin/ldconfig, /sbin/sln, /usr/sbin/iconvconfig) should be put to the separate glibc-smth package, with only one such package existing in the multiarch repo (so no conflicts). Please decide.
I'm not at all familiar with OpenVZ and how things get installed on the containers, but the macro is normally set to suitable default either from rpm default configuration or in some cases (iirc notably ppc as it's fairly special case) from anaconda. And yes, the whole multilib setup wrt rpm and packaging is a hack, fixing it all is an enormous task. See https://bugzilla.redhat.com/show_bug.cgi?id=multilib for the "master multilib" bug and it's dependants.
(In reply to comment #8) > I'm not at all familiar with OpenVZ and how things get installed on the > containers In this case you can safely assume it's just a chroot()ed environment. > but the macro is normally set to suitable default either from rpm > default configuration I guess that's what I was asking fore in comment #7, item (1) > or in some cases (iirc notably ppc as it's fairly special > case) from anaconda. We do not use anaconda for installing containers (although maybe it could be done, I'm not sure if it has options to install into a chroot() non-interactively). Generally it would be cool if all such hacks are performed in places such as rpm scripts (although I can definitely say RHEL and Fedora are much cleaner/better in this regard than say SLES/OpenSUSE). > And yes, the whole multilib setup wrt rpm and packaging is a hack, fixing it all > is an enormous task. See https://bugzilla.redhat.com/show_bug.cgi?id=multilib > for the "master multilib" bug and it's dependants. Let me then wish you an enormous amount of good luck with that then. I guess this bug can now be closed (maybe making it a dupe of an existing one). Thank you for your explanations.
I think the comments on this bug redirect any viewer to the right place. Panu, thank you, for handling this.