develooper Front page | perl.perl5.porters | Postings from August 2009

Redhat perl != perl

Thread Next
Tom Christiansen
August 12, 2009 08:01
Redhat perl != perl
Message ID:
SUMMARY: The current Redhat definition of "perl" is misleadingly 
         broken, leading to confusion and error because they've got 
         their meta-package definitions and instructions wrong.

         This must be fixed, but not by us.  Could anyone please 
	 shed light on this for me--and/or for them?

I recently had the unpleasant experience of learning how as of Federa 10,
Redhat no longer include(s) Perl v5.10 when you install their perl 5.10 RPM.

Yes, that's what I said.  

Of these, the most egregious omission is itself, as its absence
precludes the easy fix of using CPAN to grab what Redhat forgot.  Other
pieces notably missing include Text::Harness and h2xs -- although h2ph *is*
included!  Go figger. Redhat's own answer to the bug report that CPAN is no
longer being part of Perl is:

    Not a bug. You need to install the perl-CPAN package. Alternately, 
    if you want to install all of the "core" perl modules at once, you 
    can yum install perl-core.

BZZT.  They're wrong.  At the bare minimum, they should install a stub that
explains that it is not installed and why, and what to do about it--and
why.  They need to do better.  Other distributions manage this correctly;
it's Redhat who've messed up people's Perl-world.  Not nice.

The root of the problem is in their metapackage definition.  Check this
out. Redhat's current definitions are

    perl-core = perl perl-libs perl-devel + various decoupled modules 

Get that?  perl DOES NOT INCLUDE perl-core! They have perl-core as 
a SUPERSET of perl. Of the perl package itself, they write:

    "Perl is a high-level programming language with roots in C, sed, awk
     and shell scripting. Perl is good at handling processes and files, and
     is especially good at handling text. Perl's hallmarks are practicality
     and efficiency. While it is used to do a lot of different things, Perl
     s most common applications are system administration utilities and web
     programming. A large proportion of the CGI scripts on the web are
     written in Perl. 

 =>  You need the perl package installed on your system so that your system
 =>  can handle Perl scripts.  Install this package if you want to program
 =>  in Perl or enable your system to handle Perl scripts."

NOPE!  The perl package is necessary *but not sufficient* to fulfil the
highlighted condition in the description above.  It is therefore misleading
error-prone, and wrong.  In short words: they're lying.

The correct fix is to define perl as the top-level metapackage, *not*
perl-core.  Otherwise people wanting to install perl will not install the
standard distribution, and they will not be able to meet the requirement 
as they've described it.  

What seems to have happened is that they've changed they've decoupled some
aspects of the Perl core installation.  This does have a couple benefits
from their point of view.  For one, amphibious modules ("dual-lived") can
be independently updated when CPAN holds a more recent version than does
the core distribution.  But probably more ot the point from their
perspective, it allows people who haven't "bothered" to install a C
compiler to install such modules from a precompiled binary RPM.

Apparently the LSB is a bit lax about what is meant by "having perl
installed".  See this exchange involving Nick (who's right):

I don't know the best way to get this fixed, which lever needs oiling or 
calibration.  Is it "just" a Redhat blunder, or is this something for the
LSB not to dodge?  Can anybody tell me that this is *not* broken, and why?
Or what *should* happen?



   "I have yet to see any problem, however complicated, which, when looked
    at in the right way, did not become still more complicated."
                                                        --Poul Anderson

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About