Re: Redhat perl != perl

In-Reply-To: Message from Tom Callaway <tcallawa@redhat.com>
   of "Fri, 14 Aug 2009 10:53:46 EDT." <4A857A7A.2020902@redhat.com>

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

Thanks.

I certainly do *not* disagree with separately bundled sub-packages. In
fact, it has a lot to be said for it (amphibious modules async version
updates), and I do sympathize.

I agree with Andy that the best meaning of "perl" is for it to mean the
Standard Distribution, just as it once did and still does in other distros.

If you wanted to make it alias to "perl-stddistro" or "perl-complete" or
something, too, that would be fine.  I'd especially fix up the descriptions
to say whether any given package is greater than, equal to, or less than
the Standard Distribution.

The trouble is that "yuml install perl" once got the Standard Distribution
as one would expect, but that it no longer means that because you changed
what the existing perl package provided without changing its name, and you
did so in a way opposite to previous expectations with no hint of this
change in the descriptions.  This is neither backwards compatible nor well
explained, whereas it should in the best of all worlds be done in a way
that is both of those.

Chas Owens does a fine job of explaining these things in his letter
<58ce48dc0908130919n7b58c8a7k15b9c33f1a9a8ce7@mail.gmail.com>.
I'd urge Redhat to please consider Chad's points.

I'm sorry that your dependencies are worded in a way that makes them mean
something they don't mean.  Surely some were written when the only thing
they could list was "perl", not a subset. I don't know how the mechanics of
who controls what.  You imply you can't just fix your dependencies in one
fell swoop, such as making them all list instead of perl something like perl-
minimal or perl-undocumented or whatever flavors you split it into.

Now, Apple has a pretty fancy set of installation libraries, and ships MacOS-
specific modules like this:

    % pmpath Mac::AppleEvents
    /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level/Mac/AppleEvents.pm

This is nice because you can tell instantly what something is part of--
or not, as the case may be.  Watch:

    privlib='/System/Library/Perl/5.8.8';
    archlib='/System/Library/Perl/5.8.8/darwin-thread-multi-2level';
    extraslib='/System/Library/Perl/Extras/5.8.8';
    vendorlib='/Network/Library/Perl/5.8.8';
    sitelib='/Library/Perl/5.8.8';
    updateslib='/Library/Perl/Updates/5.8.8';

That said, I went through a sort of bundling difficulty with the OpenBSD
and the MacOS ports trees.  It has to do with what is in PRIVLIB vs SITELIB
vs VENDORLIB.  There are all kinds of p5-BLAH ports for various modules and
such in both those ports trees.  I'd naively thought that if CPAN stuff
went into SITELIB and ports/packages went into PRIVLIB (or VENDORLIB) it
would be ok.  But this proved unworkable: opposing / conflicting packaging
systems were just too complicated.  I couldn't replace /usr/bin/perl for
reasons of system dependencies, nor could I really share its various lib
dirs.  So my /usr/local/bin/perl has totally different values for those.

Oh well.

-tom