On Thu, 18 Apr 2002, Luke Mewburn wrote:

> 	+ All rc.d scripts will be in one directory - "/etc/rc.d"

I like that a lot (and the rest). I have one question...

> 	+ Base system configuration comes from "/etc/rc.conf"
> 	  (and any other files sourced by that file)
>
> 	+ Per application configuration comes from "/etc/rc.conf.d/$name",
> 	  where $name is the argument that the script calls
> 	  load_rc_config() with.

For the pkg_ case, does this mean the user is expected to edit
"/etc/rc.conf.d/$name" after the package creates that file? Besides the
aesthetic issue of having configuration spread about multiple files,
this will create maintenance issues if the pkg_ rc script ever needs to
add additional default variables.

If the package system has to parse and frob a file or files anyway,
I think it better if it's a file that the user never touches, like
"/etc/defaults/rc.pkg.conf". Users could then put their changes in
either /etc/rc.conf or /etc/rc.conf.d/$name, whichever suits them.

> 	+ NetBSD base system rc.d scripts:
> 		- Filename, PROVIDE, and $name must not start with
> 		  "pkg_" or "local_"
>
> 	+ NetBSD pkg rc.d scripts:
> 		- Filename, PROVIDE, and $name must start with "pkg_"
> 		- Script must  "REQUIRE: mountcritremote"
> 		  (as /usr might be a remote file system).
> 		  Other dummy dependencies (c.f. rc.d(8)) such as
> 		  NETWORKING, SERVERS, DAEMON or LOGIN can be REQUIREd
> 		  as necessary.
> 		- /etc/rc.conf.d/pkg_*  can be used for configuration.

I guess the idea is that the package system just creates that file (with
suitable defaults) if and only if it doesn't already exist. That breaks
down if the file ever needs to change. Alternatively, I think the number
of pkg_ rc.d scripts will be small enough, that we could probably craft
a single defaults/rc.pkg.conf file and include the latest version in
every binary package which has an rc.d script. ["/etc/rc.conf.d/$name"
loads after "/etc/rc.conf" in load_rc_config(), so editing the former
would still be an option.]

> 		- The NetBSD pkg maintainers are responsible for
> 		  ensuring that filename conflicts do not occur.

Having a single file with defaults for all possible scripts would make
it a lot harder to go wrong with that.

Frederick