On 9/2/06, matthew sporleder <msporleder@gmail.com> wrote:
> On 9/1/06, Ben Collver <collver@peak.org> wrote:
> > On Fri, Sep 01, 2006 at 10:06:05PM -0400, matthew sporleder wrote:
> > > >perl:
> > > >    I'm revoking this one. Perl is too large and complicated, and it's
> > > >    not required.
> > > Yes, operating systems that include perl/java/python/etc are just
> > > forcing someone to maintain two versions on their system and confuse
> > > everyone a lot.
> >
> > I've seen cluster nodes with a dozen "virtual servers", some of which
> > had multiple versions of Perl with specific build options desired by
> > specific developers.  The administrators didn't get confused.
> >
> > But having it built in leads me to wonder if it can be removed, or
> > properly upgraded.  For example, parts of Gentoo may depend on Python,
> > or parts of OSX may depend on a JVM.  How can one argue in this case
> > that it shouldn't be built in?
> >
>
> The situation goes like this:
> My very important OS utility X depends on Y.
> Y becomes old, out-of-date, insecure.
> In parallel, the OS becomes old, but not really out-of-date.  (OS's
> have more useful life than one version of perl)
> New tool Z needs updates Y, I now need two Y's.
>
> Having two Y's now means I need to mess around with #!/path/to/Y
> because, of course, my OS installed old Y in the most common place.
> :)
>
> If you can -avoid- these dependencies all together, you're in a much
> better situation to stay out of that mess.
>

Another way to avoid them, at least in perl, is to perlc all of your
utilities at build-time.  A much better solution!  This points out a
huge problem with linux distros (and many open source apps) that they
think they're doing you a favor by including some version of whatever.
 It just creates confusion and a lot of replication in /usr/local.