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