Subject: Re: Re: Re: Final plug for extra utilities
To: Ben Collver <firstname.lastname@example.org>
From: matthew sporleder <email@example.com>
Date: 09/02/2006 09:41:42
On 9/2/06, matthew sporleder <firstname.lastname@example.org> wrote:
> On 9/1/06, Ben Collver <email@example.com> 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.