[CentOS] bug in repo affecting perl

Tue Feb 14 23:59:47 UTC 2012
Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>

Nicolas Thierry-Mieg wrote:
> Blake Hudson wrote:
>> Nicolas Thierry-Mieg wrote the following on 2/13/2012 9:11 PM:
>>> why do you think there's a problem? if you have an x86_64 system, you
>>> are expected to use x86_64 perl, and that's what you have in the os
>>> and updates dir for that arch, with the newer version in updates. Same
>>> if you have an i386 system. Apparently centos extras provides the i386
>>> package for people who want that on an x86_64 system, although the
>>> version provided is the older one. ...
>>> The only possible "bug" is that extras could carry the latest i386
>>> package.
>> I have dozens of x86_64 systems. On none of them did I manually install
>> the i386 perl package. However, they all seem to have it installed.
>> It seems that in many cases CentOS installs both an i386 and an x86_64
>> package when only the base package is requested, so I have thought
>> nothing of it. install.log shows that the x86_64bit package was the only
>> one initially installed, yum indicates that the i386 package was
>> installed later (looks like during a yum update, possibly a dependency).
>> Is this a past mistake in the repo that is only rearing its head when
>> there is a mismatch between the x86_64 version in the update repo and
>> the i386 version in the extra repo? Should there even exist a version in
>> the extra repo? If so, it seems it should certainly be updated.
> yes it should be udpated.
> I was just pointing out that the i386 version you have installed must
> have come from extras, since your x86_64 system cannot see the i386
> versions available in the base+updates i386 repos that you showed in
> your original post. It seemed you were wondering why these versions were
> not being installed.

BTW: why do you need 32bit perl? Since the package exists and you have 
it installed, I guess there must be use-cases... but perl being 
interpreted, I'm curious as to what they could be.