NetBSD is an operating system with a publically available source
tree that changes on a daily basis, with an infrequent "fixed point"
release schedule.  This introduces challenges in providing a sane
upgrade path for users, especially those tracking "NetBSD-current"
and upgrading their systems at arbitrary points.

NetBSD currently has a text file - /usr/src/UPDATING - which
describes various important changes, but due to a variety of human
factors, it has not proven to be as effective at reducing end-user
inconvenience as hoped.
	
I propose the following mechanisms which should alleviate these
upgrade
issues.


1. Postinstall Mechanism
------------------------

We should provide a postinstall mechanism that will identify various
configuration issues that should be resolved before rebooting with the
new userland.

This will be a shell script, installed by /usr/src/Makefile into
/.postinstall, and will have the following syntax:

	/.postinstall  op  [item [...] ]
	op can be one of:
		help	show help, including a list of valid items

		check	tell the invoker what needs to be fixed, such as
			renamed rc.conf variables, renamed config files,
			obsolete or new rc.d scripts, etc...
		fix	fix what the check complained about

	if no items are provided, all checks or fixes are performed.

The "afterinstall" target of /usr/src/Makefile will run "/.postinstall check"

/.postinstall will be part of the base.tgz set.  Users installing from
binary snapshots will be strongly encouraged to run /.postinstall after
extracting the sets.  (We could even add a "is /dev populated ?" check :)

This mechanism could also potentially be used as part of the upgrade
mechanism in an official release.

With this mechanism in place, a lot of compatibility junk can be
removed from /etc/rc.d/*, and upgrade information in UPDATING can be
simplified.


2. rc.d namespaces for pkg and local scripts
--------------------------------------------

A common feature request has been to support non-NetBSD rc.d scripts
in a manner that doesn't potentailly cause a collision with rc.d
scripts that may be added in the base system of future NetBSD releases.

After careful consideration, the following solution is proposed.

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

	+ 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.

	+ 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.
		- The NetBSD pkg maintainers are responsible for
		  ensuring that filename conflicts do not occur.

	+ NetBSD local rc.d scripts:
		- Filename, PROVIDE, and $name must start with "local_"
		- Script should  "REQUIRE: mountcritremote"  if /usr/

If an application moves from pkgsrc to the base system (or
vice-versa), the relevant rc.d scripts would be renamed to the
appropriate standards of the target namespace.


3. rcorder dependency overrides
-------------------------------

In order to allow full end-user control over the base NetBSD rc.d
scripts without requiring editing of the scripts, a mechanism is
required which allows changing the order of the dependency tree.

Robert Elz proposed a mechanism that allows for options to rcorder(8)
to override the REQUIRE / BEFORE items of a scripts.  That idea was
suggested on a mailing list, and is in PR [16061].

With that mechanism, the following proposed rc.conf(5) variables could
be used to override the ordering of rc.d(8) scripts:	
	rcorder_flags		flags to the rcorder in /etc/rc
	rcorder_shutdown_flags	flags to the rcorder in /etc/rc.shutdown



Luke.


-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system