At 8:43 AM -0500 9/23/02, Puneet Kishor wrote:
>As usual, what I thought was a simple problem has suddenly seemed to
>balloon into a long dim einebahnstrasse that I can't back out from
>easily.
Heh. Isn't that always the case? Anyway, here's the real deal.
There are three types of modules you can fetch with CPAN.pm in one
way or another:
1) Modules that live on the CPAN as individual entities. This
includes things like Acme::Buffy or Quantum::Entanglement.
2) Modules that are both on the CPAN as standalone entities *and*
also live in one or more distributions of perl. This includes things
like libnet and CGI.pm
3) Modules that live *only* in a distribution of perl and don't live
anywhere else. This includes something like File::Basename.
There's a big module list file on the CPAN that has all the modules
in it, along with the location of archive that contains their newest
versions. That's where the problem comes in.
In case #1, when you install a module CPAN.pm just goes and gets the
archive off of the CPAN network and does the normal build thing, as
you'd expect.
Case #2 is where things get tricky. The *old* version of CPAN.pm
(which shipped with perl 5.6.0) would look at the module file, see
that the location for the newest version of something was in, say,
per-5.8.0.tar.gz (because the module had been rolled into the
distribution). CPAN.pm would happily then fetch that perl
distribution and build it. Newer versions of CPAN.pm were clever
enough to notice that it was doing The Wrong Thing and fetch the
newest version that wasn't rolled into a perl distribution, hence the
advice to install the newest version of CPAN.pm
You can't safely install the newest version of CPAN.pm by installing
Bundle::CPAN, as some of the things in Bundle::CPAN are in 5.8.0's
distribution. Once you have the latest CPAN.pm in, then you can
install Bundle::CPAN, as you'll then get the module versions not in
the core distributions.
Case #3 is a pain, but there's not much for it. There are modules
that live *only* in the core distribution, and the only way to get
them is to fetch the core distribution and install it. Needless to
say, this is annoying, but, well, what else is there to do?
>pk/
>
>A funny thought comes to mind... in a recent, long, but very
>interesting thread, some of us complained how Apple can't get it
>right, and with every upgrade of the OS things change and break. If
>anything, perl is an even bigger culprit at this... I mean, from
>what I have learned vicariously, perl 5.8.0 is not even binary
>compatible with perl 5.6.x and everything breaks on upgrading unless
>cautious vigilance and voodoo are practiced. And I am sure that perl
>is only a fraction as complex as the operating system is...
Couple of things here.
Perl's C API suffers from design issues that date back to the
original 5.000 release. There were things that seemed like a good
idea at the time that have, in hindsight, turned out not to be such a
good idea. (Things like exposing structure definitions to extensions
and using macros rather than functions as accessors) There's not much
to be done short of completely rewriting things from scratch. Which
we're doing with perl 6. :)
Perl went through a binary API incompatibility when moving from 5.005
to 5.6.0, and again when going from 5.6.0 to 5.8.0. Nobody liked it
(believe me, we *really* don't like it) but there wasn't much for it.
(5.004 and 5.003 were compatible with 5.005. I don't remember past
that)
Apple also mildly screwed up when they built perl 5.6.0. The settings
chosen for the library paths eliminated the version directories in
the library path, which makes multiple coexisting versions of perl in
the same library tree somewhere between difficult and impossible.
Perl has some library layout issues that exacerbate this, though
those have been addressed in more recent versions of perl. (I don't
remember if they were completely addressed by 5.6.0)
FWIW, while perl is a smaller project in many ways than OS X, perl
also has *far* less engineering talent on hand. It's an all-volunteer
project which, unfortunately, limits the amount of time and effort
anyone can put into it. Apple, on the other hand, can hire and pay as
many engineers as it has to to get a project going. More importantly,
it can pay people to do the stuff that's not particularly fun, like
maintaining API compatibility and suchlike things. While perl does
have people who work on that, it's not a job that too many folks are
willing to do without any external incentive. (That we have some is a
testament to the project, but still, we can always use more)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
