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-m...
On 15/06/2010 21:10, m.roth@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