Date: Thu, 10 Apr 1997 18:52:44 +1000 (EST) From: proff@suburbia.net To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: nate@mt.sri.com, msmith@atrad.adelaide.edu.au, terry@lambert.org, sef@kithrup.com, hackers@FreeBSD.ORG Subject: Re: on the subject of changes to -RELEASEs... Message-ID: <19970410085245.11057.qmail@suburbia.net> In-Reply-To: <20842.860656023@time.cdrom.com> from "Jordan K. Hubbard" at "Apr 10, 97 00:07:03 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970410085245.11057.qmail>