From owner-freebsd-hackers Mon Sep 25 18:53:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03767 for hackers-outgoing; Mon, 25 Sep 1995 18:53:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03762 for ; Mon, 25 Sep 1995 18:53:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06533; Mon, 25 Sep 1995 18:49:26 -0700 From: Terry Lambert Message-Id: <199509260149.SAA06533@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 18:49:26 -0700 (MST) Cc: kelly@fsl.noaa.gov, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, gryphon@healer.com In-Reply-To: <199509260056.UAA14148@healer.com> from "Coranth Gryphon" at Sep 25, 95 08:56:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1523 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Unless /etc is read-only and the only method you have to add your own > > stuff is union mounts (additional directory entries). > > In which case, you've set up a very unique configuration, where > you cannot change "motd", cannot edit password files, change mail > aliases, add new hosts to DNS, ... The motd should be in var. Local passwords not in the NIS database or user IDs needed for boot should be in var. Mail aliases should be handled by the mail exchanger host; those that are local to the local machine should be in the users' personal alias database. or they should be in var. DNS server/caching databases should be in var. A client DNS configuration is not subject to change by the client. > These types of changes are at least as common, if not a lot more so, > than adding packages. Only because we have local system information in the wrong damn place, which is why we don't have the ability to upgrade in the first place (upgrade/addition-of-options is what started this whole thread). If the /etc/rc file was completely data-driven, it wouldn't need to be modified. If it didn't need to be modified, then upgrade would not be a problem (you'd just overwrite the thing). If configuration data lived in its own place, you'd update everything but that place, and you'd be upgraded (you'd overwrite all of /etc). An upgrade is a typical user operation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.