From owner-freebsd-hackers Sun Nov 26 15:37:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA12058 for hackers-outgoing; Sun, 26 Nov 1995 15:37:36 -0800 Received: from multivac.orthanc.com (root@multivac.orthanc.com [204.244.20.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA12041 for ; Sun, 26 Nov 1995 15:37:26 -0800 Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7/8.7) with SMTP id PAA13606; Sun, 26 Nov 1995 15:37:11 -0800 (PST) Message-Id: <199511262337.PAA13606@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg (VE7TCP) To: peter@taronga.com (Peter da Silva) cc: hackers@freebsd.org Subject: Re: More nits In-reply-to: Your message of "Sat, 25 Nov 1995 19:27:50 CST." <199511260127.TAA28662@bonkers.taronga.com> Date: Sun, 26 Nov 1995 15:37:10 -0800 Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "Peter" == Peter da Silva writes: 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). 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). Peter> a "gnu developer" pack, with gmake and so on... Well, just about everything developer related already *is* GNU. Make is one of the few that isn't there by default. I'm not a big fan of GNU make (the 4.4BSD make is much more elegant) and would prefer not to encourage its use. Peter> a "gnu X" pack, ghostview, ghostscript, ... This should probably be a generic "Postscript" package. Peter> a "mh" pack, with mh, vmail, xmh, ... As long as xmh will be ignored properly on systems that don't have X installed. 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. The ports software should be configured to install into either the standard directory tree, or into a seperate /usr/ports hierarchy. --lyndon