Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tom Christiansen <tchrist <at> perl.com>
Subject: Re: Redhat perl != perl
Newsgroups: gmane.comp.lang.perl.perl5.porters
Date: Friday 14th August 2009 18:56:27 UTC (over 8 years ago)
In-Reply-To: Message from Tom Callaway 
   of "Fri, 14 Aug 2009 10:53:46 EDT." <[email protected]>

> 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
<[email protected]>.
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
 
CD: 3ms