Bug 437251

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.