Bug 437251 - yum says it installed glibc.ppc and glibc.ppc64 but there's no ppc64 package
yum says it installed glibc.ppc and glibc.ppc64 but there's no ppc64 package
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-13 04:52 EDT by Kir Kolyshkin
Modified: 2014-01-21 18:02 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-13 09:14:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kir Kolyshkin 2008-03-13 04:52:41 EDT
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
Comment 1 Kir Kolyshkin 2008-03-13 04:59:47 EDT
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?
Comment 2 Kir Kolyshkin 2008-03-13 05:00:56 EDT
Same happens with yum-3.2.8-2.fc8 -- says it installed both arches, but there is
no ppc64 in rpm -q output after.
Comment 3 Panu Matilainen 2008-03-13 05:05:30 EDT
What does the following command output on your system:
rpm --eval "%{_transaction_color}"
Comment 4 Kir Kolyshkin 2008-03-13 05:19:07 EDT
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
Comment 5 Kir Kolyshkin 2008-03-13 05:19:48 EDT
I have also checked the issue on another container running F7 -- it's all the same.
Comment 6 Panu Matilainen 2008-03-13 05:36:49 EDT
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
Comment 7 Kir Kolyshkin 2008-03-13 07:46:39 EDT
(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.
Comment 8 Panu Matilainen 2008-03-13 08:14:08 EDT
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.
Comment 9 Kir Kolyshkin 2008-03-13 09:07:27 EDT
(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.
Comment 10 Seth Vidal 2008-03-13 09:14:50 EDT
I think the comments on this bug redirect any viewer to the right place.

Panu, thank you, for handling this.

Note You need to log in before you can comment on or make changes to this bug.