From owner-freebsd-hackers Thu Apr 10 01:53:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA24652 for hackers-outgoing; Thu, 10 Apr 1997 01:53:36 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA24647 for ; Thu, 10 Apr 1997 01:53:34 -0700 (PDT) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id BAA26888 for ; Thu, 10 Apr 1997 01:55:47 -0700 (PDT) Received: (qmail 11058 invoked by uid 110); 10 Apr 1997 08:52:45 -0000 Message-ID: <19970410085245.11057.qmail@suburbia.net> Subject: Re: on the subject of changes to -RELEASEs... In-Reply-To: <20842.860656023@time.cdrom.com> from "Jordan K. Hubbard" at "Apr 10, 97 00:07:03 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 10 Apr 1997 18:52:44 +1000 (EST) Cc: nate@mt.sri.com, msmith@atrad.adelaide.edu.au, terry@lambert.org, sef@kithrup.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] 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 > However, if you were to say that everything in /etc should depend on a > single writable configuration file, I wouldn't argue with the > principle (and it's what I had in mind for /etc/sysconfig) but simply > point to the fact that "everyone" knows about files like > /etc/resolv.conf too, and if you put "domain=blah.com" and > "resolver1=foo .. resolvern=bar" lines into /etc/sysconfig and > made resolv.conf redundant (or removed it) there would be a lot of > confusion. > > Jordan A reliable union layer would solve all these cases where one has a standard "template" file that may or may not receive modification. Upgrades of template files then wouldn't be an issue due to their nature -- i.e an upgrade in the comments on the /etc/hosts file probably has little value, and the operator can refer back to the lower layer if they have any doubt. The those files that are not template files, (e.g scripts like rc*), there needs to be hooks at various stages of the process with which external user-modfications can intervene. i.e if rc is broken up into 20 different files, each file can test for the presence of a user generated replacement, or intermediary for the next file before calling it. The current /usr/local/etc/rc.d/foo.sh method of starting deamons is a podge. Both distribution and local startup sequences could do well with a dependency configuration system controlling their activation sequence. e.g an /etc/options which contains files with the name of each package, and the contents being a list of dependencies that need to be satisfied and the initialisation script to run to satisfy them. Here's a depraved idea (it gives me warm fuzzy feeling though) make(1), controls the entire startup (and shutdown?) sequence ;) I'll let you ruminate on that Jordan, I think it's just the kind of thing you could Enjoy. Cheers, Julian.