[ On Thursday, April 18, 2002 at 08:22:45 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: post-installation and rc.d enhancements
>
> "Chaining" is ugly and complicated, and denies the user the ability to
> arbitrarily set the order the scripts are executed (barring re-writing
> the whole mechanism).

Perhaps I didn't make it clear in my proposal that there's no such
fundamental restriction in its design, and a major re-design is
explicitly avoided.

There are at least two alternative ways to execute rc.d scripts
contained within my proposal.  One of those alternatives allows for
arbitrary ordering of scripts between hierarchies.  They are necessary
as alternatives though due to external constraints which must be
supported in the design (i.e. allowing for installation of add-on
sofware on separate filesystems).

Under my proposal each hierarchy of add-on software will include with
its own etc/rc.d sub-directory with its own set of scripts, just like
the base system, thus preserving namespace separation for the script
file names themselves.  I suggest these alternatives can be chosen
between by the user "at run time" depending on their particular
cirumstances.

	1. all those hierarchies which live on the root partition _may_
	   have their rc.d scripts mixed with the base ones in /etc/rc.d
	   by specifying the additional directories in /etc/rc.conf in a
	   list called $more_rc_d.  Here's what I have in my /etc/rc to
	   do this (and have been using successfully for over a year):

		_all_rc_d_files=""
		for _rc_d in /etc/rc.d ${more_rc_d} ; do
			if [ -d $_rc_d -a ! -h $_rc_d -a ".$(echo ${_rc_d}/*)" != ".${_rc_d}/\*" ]; then
				_all_rc_d_files="${_all_rc_d_files} $(echo ${_rc_d}/*)"
			fi
		done
		
		ordered_rc_d_files=$(rcorder ${_all_rc_d_files})
		
		for _rc_elem in $ordered_rc_d_files; do
			$debug_echo run_rc_script $_rc_elem start
		done

	   in addition the rc.d scripts in $more_rc_d directories would
	   source $PREFIX/etc/rc.conf instead of sourcing /etc/rc.conf,
	   and would source $PREFIX/etc/rc.conf.d/$name instead of
	   sourcing /etc/rc.conf.d/$name in order to keep the
	   configuration variable (and action) namespaces separate.

	2. if a hierarchy must live on a separate partition (i.e. not on
	   the root partition) then its scripts are run as a separate
	   group, either after those in the root directory, or even as a
	   group in between two root-level rc.d scripts (i.e. in a
	   separate invocation of '/etc/rc -p $PREFIX' called by an
	   /etc/rc.d script).

I.e. you can mix the ordering of your add-on scripts with system scripts
if you're willing to install your software on the root filesystem.

Now obviously it's only the rc.d scripts themselves which must be
installed on the root filesystem.  Therefore implicit in my proposal is
the ability for a user to install applications on a separate filesystem
but by virtue of a symlink in place of their $PREFIX/etc directory (or
maybe even just $PREFIX/etc/rc.d) be able to re-direct those necessary
files to actually live on the root filesystem.  Therefore in some senses
the second alternative, i.e. this whole "chaining" idea, is not really
necessary at all.  It can even be converted to this form after package
installation has happened.  I only propose it because it might be an
easier way to support some groups of users.

I haven't actually implemented the second alternative though, at least
not in a way that's integrated cleanly with the first alternative (which
I now use).  (Others have posted examples of it, but also not in any way
integrated with my proposed first alternative).  However it should be
quite straight forward to do and I'm willing to give it a try....

I should also note that in my current implementation of the "mixed
root-level multiple rc.d directories" first alternative I have not yet
implemented a separation of configuration information as discussed
above.  This would be quite straight forward to do, but I've avoided
doing so for now as I have no immediate requirement to have rcvar name
collisions (by sheer luck of calling my SSH-V2 package "ssh2", and also
by learning to call drop-in sendmail-compatible mailer packages by their
own names instead of pretending they are also called sendmail :-).  It
does involve some significant changes to the internals of /etc/rc.subr
and I've tried to keep my local changes to that file easier to merge for
the time being.


> Shades of "rc.*.local".

I don't think that's a fair comparison at all.  Having a $PREFIX/etc/rc
script that works just like /etc/rc is not just shades of rc.d -- it's a
literal copying of the concept so as to keep the hierarchies 100%
consistent in design and usage with the base system.  Even with a
chaining mechanism it's quite distinct (at least in my mind! :-).


> Moreover, as long as you
> have protected namespaces, all the scripts *can* go in the same
> directory, so why make it complicated?

Well unless the basename derived namespace trick is made a bit more
complex it is too inflexible.

It's also quite a bit of shell magic an trickery that I fear will spread
some of the complexities currently hidden deep inside /etc/rc.subr out
into the individual rc.d scripts.  In order to be written portably they
will have to know where they are installed in order to derive their
rcvar name.

In other words I really do not like namespaces that have to be
implemented by modifying filenames and variable names.  The use of
separate directories keeps rc.d scripts under my proposed scheme 100%
identical to their current form and makes them 100% portable between
hierarchies (i.e. totally independent of which $LOCALBASE they are
installed in), while at the same time allowing for multiple copies to be
installed simultaneously, each in different hierarchies (including one
in the base system), and even each all be started at boot (obviously
with any conflicting features appropriately re-directed to allow
simultaneous execution, such as different listen-on ports for named).

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>