Bug 294021 - latest perl-5.8.8-23.fc7 broken with fc6xen reference
latest perl-5.8.8-23.fc7 broken with fc6xen reference
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
7
i386 Linux
low Severity urgent
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
: 245592 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-17 17:59 EDT by David Favor
Modified: 2007-11-30 17:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-18 09:42:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Favor 2007-09-17 17:59:41 EDT
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.
Comment 1 David Favor 2007-09-17 18:00:46 EDT
This is a follow on to bug 286581.
Comment 2 Tom "spot" Callaway 2007-09-18 09:42:57 EDT
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.
Comment 3 David Favor 2007-09-18 10:51:03 EDT
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.
Comment 4 Tom "spot" Callaway 2007-09-18 11:05:09 EDT
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.
Comment 5 Tom "spot" Callaway 2007-11-06 16:15:14 EST
*** Bug 245592 has been marked as a duplicate of this bug. ***
Comment 6 Ian Burrell 2007-11-06 18:34:13 EST
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.
Comment 7 Tom "spot" Callaway 2007-11-07 09:34:05 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.