Features Download
From: Tom "spot" Callaway <tcallawa <at> redhat.com>
Subject: Re: Redhat perl != perl
Newsgroups: gmane.comp.lang.perl.perl5.porters
Date: Friday 14th August 2009 14:53:46 UTC (over 8 years ago)
On 08/12/2009 10:59 AM, Tom Christiansen wrote:
> 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?

Hi Tom,

Since I am the individual who originally did the split, I would like to
take the opportunity to explain.

At the time of the split, we had a LOT of packages which depended on
simply "perl". We also had a lot of people who wanted individual perl
modules updated that live within the "perl tarball", which is a
complicated task to undertake. By splitting the perl modules out into
separate subpackages we were at least able to allow people to build
newer RPMs. In addition, the split had the added benefit that people who
did not need nor want all of the components built with perl could get a
system without them. This lowered the default Fedora installation

At the same time, there were cries that we needed some way for folks to
be able to get the "full perl experience as intended by Perl upstream",
so I created the "perl-core" metapackage, which has hardcoded requires
to pull in all of the perl bits that were previously all packaged
together in the monolithic "perl" RPM.

Also, we were getting a LOT of bugs from people who were installing
things from CPAN which conflicted in ways with the Fedora packages. It
is worth noting that since then, we have configured perl such that CPAN
installed packages go into /usr/local and are preferred over system
packages. The logic path was that users who wanted CPAN could still
easily get it, but they were now making a conscious choice to do so, and
could no longer claim that they didn't know what they were doing (a very
common complaint in Fedora bug reports).

Okay, so with all of that said, let me discuss what would happen if we
were to switch the naming of perl and perl-core tomorrow:

* Any packages which still have "Requires: perl" , rather than a more
specific "Requires: perl(foo::bar)" would suddenly have a much larger
installation footprint. (Thankfully, I think this is probably almost
never the case in current Fedora as a result of many cleanups.)
* New users who do not read the descriptions (which, unfortunately, are
far more than those who do) and run: yum install perl, will get more
perl modules than they possibly want or need. I realize that this is a
hotly debatable point.
* Existing users who are currently happy with the focused perl packages
that they have installed (only those which are explicitly needed by
dependencies) will suddenly get a lot more perl subpackages which they
are not using upon the next update/upgrade. This leads to cries of "OMG

I see four possible courses of action at this point:

1. Go back to a monolithic perl. I do not like this option, and I would
not recommend it.
2. Reword the descriptions to make it much clearer that the "perl"
binary package, and the dependencies it has, is not the complete "core"
as provided in the perl tarballs, it is simply the minimal necessary for
/usr/bin/perl to run. (We probably want to do this anyways.)
3. Swap the perl and perl-core names, with the above results.
4. Rename perl / perl-core to something more obvious. We could convert
what is now "perl" to "perl-minimal", for example, but what if someone
runs "yum install perl"? What should they get? The minimal or the
"everything in the tarball" experience? (When this split was first done,
because of the hardcoded dependencies on "perl", we chose to make it be
the minimal experience to minimize the install footprint of Fedora and
its applications, but now, I think we should be able to get away from

As to the cries that Red Hat is somehow "destroying perl", I can
honestly say that is not the case. The perl package has several active
maintainers and Fedora has an active perl packaging community which
works very hard to deliver the best possible perl experience for Fedora
users. Yes, we hit bugs, and make mistakes, but we are constantly trying
to fix those bugs as well. Keep in mind that Fedora was one of the first
distributions to adopt 5.10.0, which required quite a lot of effort and
work with the p5p community.

Constructive and polite comments and discussion are welcomed, either on
fedora-perl-devel-list or on p5p.


Tom "spot" Callaway
CD: 4ms