From owner-freebsd-hackers  Sun Nov 26 16:10:34 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id QAA15360
          for hackers-outgoing; Sun, 26 Nov 1995 16:10:34 -0800
Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA15349
          for <hackers@freebsd.org>; Sun, 26 Nov 1995 16:10:23 -0800
Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA15466
  (5.67a/IDA-1.5); Sun, 26 Nov 1995 17:52:27 -0600
Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id RAA27087; Sun, 26 Nov 1995 17:51:08 -0600
From: peter@taronga.com (Peter da Silva)
Message-Id: <199511262351.RAA27087@bonkers.taronga.com>
Subject: Re: More nits
To: lyndon@orthanc.com (Lyndon Nerenberg)
Date: Sun, 26 Nov 1995 17:51:07 -0600 (CST)
Cc: peter@taronga.com, hackers@freebsd.org
In-Reply-To: <199511262337.PAA13606@multivac.orthanc.com> from "Lyndon Nerenberg" at Nov 26, 95 03:37:10 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1278      
Sender: owner-hackers@freebsd.org
Precedence: bulk

>     Peter> a "gnu bonus pack" with all the "standard" gnu tools would
>     Peter> be good.

> How do you handle namespace collisions? I would agree with this
> iff the utilities were installed somewhere outside of the standard
> PATH (i.e. in /usr/gnu/bin).

If they're installed from packages they'd be in /usr/local/bin.

I personally like having a /usr/gnu/bin myself.

>     Peter> a "tcl/tk bonus pack" is of course required, tcl, tk,
>     Peter> tcldp, expect, ...

> TCL and TK are useful enough that they should be part of the base
> distribution (as is perl).

Been there, done that, they decided that they didn't want it. Got a bmaked
tcl rotting on freefall.

> My biggest complaint with the ports stuff right now is the way it
> scribbles all over /usr/local. Even worse, it isn't consistent (e.g.
> binaries installed in /usr/bin and support stuff under /usr/local/lib).
> /usr/local should be HANDS OFF to the vendor-supplied software, something
> I consider "ports" to be.

Ah, but the "vendor" doesn't.

> The ports software should be configured to install into either the
> standard directory tree, or into a seperate /usr/ports hierarchy.

I'd buy that. I like organizing things that way myself. But it's certainly
not what I'd call a super-high priority.