Subject: Re: /etc/rc. use bsd.rc.mk instead.
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 12/03/1999 14:44:40
[ On Friday, December 3, 1999 at 08:23:00 (-0800), Eduardo E. Horvath wrote: ]
> Subject: Re: /etc/rc. use bsd.rc.mk instead.
> [ On , December 4, 1999 at 00:22:11 (+1100), Julian Assange wrote: ]
> > pkgsrc shows make(1) can be succesfully retargeted to
> > strange new dependency domains. rc should gain the
> > same treatment.
Indeed! I was hoping someone would point this out explicitly.... :-)
> I pointed this out the last time we had this discussion and the
> objections were that nobody wanted to depend on make running in single
> user mode to bring the system up.
Whomever said that was either not thinking very clearly, or perhaps was
trying to avoid the issue by mis-directing. Obviously make could be
moved from /usr/bin to /sbin (with a link to /bin) and be statically
linked if this implementation were done.
I seem to recall mentioning then that "make" might not be the ideal
dependency maintenance tool for this job. I personally do like the
concept of a more restricted finite state machine a little bit better.
Of course makefiles can be written in such a way that a fully enclosed
FSM is defined, but I think makefiles have way too much rope and indeed
their use in this context would be too novel and would be too error
prone. Even SysV's init has a lot of rope, especially when the "states"
are not named (just numbered, and not necessarily in any logical order)
and when the state change rules are encoded in shell scripts, but at
least there the prior art sets out some fairly well understood
expectations of what will happen.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>