Karanbir Singh wrote: > 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. > In this particular instance, is removing perl.i386 the right thing to do? Are there any common situations where it would be used on an x86_64 system? -- Les mikesell lesmikesell at gmail.com