From owner-freebsd-hackers Sun Jun 23 23:33:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA27909 for hackers-outgoing; Sun, 23 Jun 1996 23:33:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA27900 for ; Sun, 23 Jun 1996 23:33:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id XAA27197; Sun, 23 Jun 1996 23:29:48 -0700 From: Terry Lambert Message-Id: <199606240629.XAA27197@phaeton.artisoft.com> Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist To: mrm@MARMOT.Mole.ORG (M.R.Murphy) Date: Sun, 23 Jun 1996 23:29:48 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <199606231619.JAA06661@meerkat.mole.org> from "M.R.Murphy" at Jun 23, 96 09:19:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The problem I have with scripting will continue to be a problem until > > the /etc/rc* data embedding mess goes away so I can upgrade a system > > by overwriting everything but "/var/conf", or a similar directory, > > and by leaving the /home partition alone, with nothing else sacred. > > Your problem with scripting may not be _MY_ problem with scripting. > That's why scripting is a good thing. ;-) 8-P. > It lets each of us tailor the behavior of a system as may be required > for our own use without having it be a major hassle. Minor hassle to > be sure, but not major, mostly. One tailored, upgrade becomes a hassle because of the interface provided for tailoring, and the non-existant guidelines for doing it in a non-impactful way. > I don't have a /home partition. Other folks do it a different way. > Some people like tomatoes. Actually, only aliens like tomatos; that's how you recognize them. 8-) 8-). Really, that you don't put your users in /home is irrelevant. What is relevant is that you put them some place other than a directory that gets upgraded directly as part of the process (and which, in an SCO or other commercial system would be recognizable from its lack of mention in the component/file mapping list that was created when the system was installed). > It would be presumptuous of me to dictate to them how they should > configure their systems. Unless it was your job to provide the upgrade software. Which it is. 8-). > For me to suggest that a cleanup of /etc/rc* would be a bad thing > would be pretty silly on my part. I get to clean it up each time > I put in a production system. I get to clean up permissions and > ownership each time, too, and strip out cruft and insert what I > deem to be of hrrrumph critical importance. For the systems that > I'm just dinking with what the FreeBSD team have put together, I'm > either happy or resigned to leaving it the way they wanted, depending > on my mood. They've done a really good job, especially considering the > loosely-coupled development environment. It's damned amazing! I agree. Could be even more amazing, too. > However, I'd consider anything that makes it very much harder for me > to make it the way I want it to be to be pretty much ill-conceived. Me too; that includes me wanting to make my system run the latest and bgreatest code and still be upgradable when a release is cut. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.