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@xxxxxxxxx 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
