Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Deinstall perl yum -y remove perl rm -rf /usr/lib/perl5 /usr/lib64/perl5 2. Install perl.x86_64 and perl.386 yum -y install perl 3. No a hard-coded reference to fc6xen shows up in both: find /usr/lib/perl5 -exec grep -l fc6xen {} \; 2>/dev/null /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Config.pm /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Errno.pm /usr/lib/perl5/5.8.8/i386-linux-thread-multi/Config_heavy.pl net1#find /usr/lib64/perl5 -exec grep -l fc6xen {} \; 2>/dev/null /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config.pm /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Errno.pm /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config_heavy.pl Now for an ugly fix: 1) Remove perl.i386 yum -y remove *.i386 2) Run http://RadicalHealth.com/perlfixosvers on a system. For the fix to actually be written into files the "#`fix`" line must be uncommented. net1#perlfixosvers Mismatch between perl=2.6.20-1.2962.fc6xen and system=2.6.22.5-76.fc7 -> find /usr/lib64/perl5 -type f -exec grep -l '2\.6\.20-1\.2962\.fc6xen' {} \; 2>/dev/null -> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config.pm -> perl -pi -e 's/2\.6\.20-1\.2962\.fc6xen/2.6.22.5-76.fc7/g' /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config.pm -> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Errno.pm -> perl -pi -e 's/2\.6\.20-1\.2962\.fc6xen/2.6.22.5-76.fc7/g' /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Errno.pm -> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config_heavy.pl -> perl -pi -e 's/2\.6\.20-1\.2962\.fc6xen/2.6.22.5-76.fc7/g' /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config_heavy.pl Doing other searches this same problem also shows up in php, so something is broken in a build process somewhere such that fc6xen is set into configs for different programs. This situation first started about three weeks ago.
This is a follow on to bug 286581.
It's also completely wrong. The kernel version set in Config.pm into osvers is from the kernel running on the machine which builds the perl package. It is NEVER EVER COMPARED with the kernel running in your environment. The Fedora buildservers are running FC6. Each package is built inside a Xen instance, running mock. Thus, osvers is set to 2.6.20-1.2962.fc6xen. Perl is not broken, this is how it functions. If perl ever compared osvers to the running system kernel, every single kernel update would require a new perl package to be respun. This is not the case. Please go back and reread what I wrote in 286581.
The following appears to by CPAN specific. Using CPANPLUS seems to work, so I'll just switch. And it's still unclear why this just started a few weeks ago and has been working fine from FC5-FC7. net1#perl5.8.8 -MCPAN -e 'install CPAN' CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Mon, 10 Sep 2007 18:36:46 GMT CPAN: LWP::UserAgent loaded ok Fetching with LWP: ftp://cpan.pair.com/pub/CPAN/authors/01mailrc.txt.gz LWP failed with code[500] message[Errno architecture (x86_64-linux-thread-multi-2.6.20-1.2933.fc6xen) does not match executable architecture (x86_64-linux-thread-multi-2.6.20-1.2962.fc6xen) at /usr/lib/perl5/site_perl/5.8.8/Errno.pm line 11.
OK, you've got several issues: #1. /usr/lib/perl5/site_perl/5.8.8/Errno.pm did NOT come from the Fedora perl package. The Fedora perl package puts Errno.pm in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Errno.pm Please look at /usr/lib/perl5/site_perl/5.8.8/Errno.pm It seems to have a hardcoded check for 2.6.20-1.2933.fc6xen. Compare it to /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Errno.pm It has a hardcoded check for 2.6.20-1.2962.fc6xen. Both files are sourcing /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Config.pm for osvers, which has osvers set to 2.6.20-1.2962.fc6xen I'm still not entirely sure how you managed this, but the Fedora files are correct.
*** Bug 245592 has been marked as a duplicate of this bug. ***
My guess of how people got a site_perl Errno is by doing "install Bundle::RT" through the CPAN shell. Errno is included in the list of modules in that bundle. The CPAN shell will upgrade modules listed in a bundle to the most recent version. That includes core Perl modules that have a separate distribution like Errno. The site_perl Errno module is tied to the exact Perl binary that compiled it. When the perl rpm is upgraded, this version check breaks.
(In reply to comment #6) > My guess of how people got a site_perl Errno is by doing "install Bundle::RT" > through the CPAN shell. Errno is included in the list of modules in that > bundle. The CPAN shell will upgrade modules listed in a bundle to the most > recent version. That includes core Perl modules that have a separate > distribution like Errno. Hrm. You should probably file that against upstream Bundle::RT, to get them to stop doing that.