On Wed, 3 Oct 2001, Charles Shannon Hendrix wrote:
> On Tuesday 02 October 2001 07:32 am, Herb Peyerl wrote:
> >
> > That a scripting language needs a built-in mechanism to go out to the
> > world to retrieve the things it needs to operate, is a clear indication
> > to me of it's inadequacy of design.
>
> No, CPAN is just a convienience.  It's thorns have nothing to do with the
> design of the language.  Ruby, C, C++, *ALL* languages if they are used
> this way will have a huge dependency graph.
>
> Perl has faults, but this isn't one of them.

Sounds to me like you're really saying the same thing -- not
criticizing CPAN in particular, as much as the need for it.

On first thought, it seems like perl in the base tree would be less
trouble to maintain than perl in pkgsrc. You could simply update it in
place, and only fix the broken modules, rather than being required to
rebuild every single package that depends on perl. Then I realize,
you'd need to run some kind of script at install time to clean out the
old crud (which is heretofore unprecedented in basesrc), and then of
course, nearly every perl module would have to either go in the tree,
too, or be fixed in such a way that it runs on every NetBSD version
ever released, and thus with every perl version greater than or equal
to the version that's first imported. This last looks to be
impossible: look at all the problems we've had with moving openssl
into the base system, and the packages that depend on openssl only
need to be recompiled, not re-written. [I think the openssl move will
pay off in the long run, but I'm not sure about perl.]

Frederick