CentOS - Jun 2010 - yum force

I'm trying to do an update to some servers... and they have both i386 and
x86_64 perl. The latter won't update, because the idiotic *man pages* are
dups. Is there *any* way, short of using rpm directly with a --force, to
get yum to ignore the dups and do the update?

And why does *anyone* make it so that a dup manpage is a reason to fail
(and don't tell me they do it generically for any of the packages in the
.rpm...)?

          mark

On 06/16/2010 06:10 AM, m.roth at 5-cent.us wrote:
> I'm trying to do an update to some servers... and they have both i386
and
> x86_64 perl. The latter won't update, because the idiotic *man pages*
are
> dups. Is there *any* way, short of using rpm directly with a --force, to
> get yum to ignore the dups and do the update?
Yes, this is frustrating.  I've encountered it a number of times while
packaging perl modules that override those in the core (e.g.
Test::More).  Sorry, but I've never found a really good solution beyond
--force or --replacefiles.
> And why does *anyone* make it so that a dup manpage is a reason to fail
> (and don't tell me they do it generically for any of the packages in
the
> .rpm...)?
Thinking this through from the rpmdb's perspective, which of the two
packages 'owns' the man pages.  If you were to, say,

	rpm -e perl.i386

would you expect it to remove the man pages or not.  What would you expect

	rpm -V perl

to report in either case.  As far as I'm aware there is no such
'duplication' logic in the db. It would be cool if it could be made to
work in general, however, I can think of some use cases that might rule
this out.  By using --force (or --replacefiles) you are effectively
breaking the consistency of the install/upgrade/remove logic and yum
should protect you from doing that by accident.

Stepping back a bit, why do you need both perl.i386 and perl.x86_64
packages?  Which package 'owns' the /usr/bin/perl executable?
None of my Centos 5 x86_64 systems have both and they have all gone
through a recent perl upgrade, so I'm curious how you got both installed
in the first place.  Is there some dependency that pulled in the i386
package?

Kal

Hi,

A bit of history is in order here:
http://www.karan.org/blog/index.php/2010/06/17/why-is-there-a-perl-i386-in-my-x86_64-install

On 15/06/2010 21:10, m.roth at 5-cent.us wrote:
> I'm trying to do an update to some servers... and they have both i386
and
> x86_64 perl. The latter won't update, because the idiotic *man pages*
are
> dups. Is there *any* way, short of using rpm directly with a --force, to
> get yum to ignore the dups and do the update?
I dont think that was the issue at all :)
> And why does *anyone* make it so that a dup manpage is a reason to fail
> (and don't tell me they do it generically for any of the packages in
the
> .rpm...)?
Its an artifact from the idea of multilib and its implementation in rpm,
docs that md5 match between builds archs' of the same package are
silently ignored. The other way to look at this is that two builds, for
the same source will produce identical outputs if built under the same
conditions ( makefiles, arch, buuild roots, dep chains, machine
conditions etc ). When you extend that over multiple arch's, the docs
are the only thing you need to be concerned about, since the binaries
you get will depend on what and how the multilib policy is implemented
on the machine. If you find there are conflicts in
package-vers-release.arch where arch is the only variant - file a bug
report; something in the buildsystem isn't doing its job right.

so, in summary : the problem you were seeing was not caused by a dupe
manpage, it was caused by a dupe manpage from different versions of perl
( had the version been the same, and the md5's for the doc's been the
same, they would not cause a conflict ).

There are different ways to handle this situation, but to be honest, I
dont see much fault with the way things are right now with rpm multilib
policy. it works.

- KB