On Sat 2000-09-09 (11:25), Matthew Thyer wrote:
> Don Lewis wrote:
> > 
> > On Sep 9, 12:05am, Matthew Thyer wrote:
> > } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d
> > } Neil Blakey-Milner wrote:
> > 
> > } > I'd prefer a dependency based system.  (cf. Eivind Eklund's newrc, at
> > } > http://people.FreeBSD.org/~eivind/newrc.tar.gz)
> > 
> > How does this compare with what NetBSD implemented?
> > 
> > } I haven't looked at this yet but off the top of my head, a dependency
> > } based system sounds overly complicated (consider ports authors) and
> > } unecessarily different from other systems.
> > 
> > NetBSD switched to a dependency based system a while back.  Judging by
> > the traffic on their mail lists, it was somewhat controversial ...
> I'd consider it overly complicated because:
> - The OS vendor can work out the correct order for system component
>   startup and set the numbers right once per release so who needs
>   the overhead and complexity of a dependency based system ?

We don't work with machines "once per release".  Keeping those numbered
files in CVS will also suck if we rearrange things.

You're making an assumption that there is overhead and complexity in a
dependency-based system.  The NetBSD one seems incredibly no-nonsense
and direct - the core of /etc/rc is:

files=`rcorder -s nostart /etc/rc.d/*`

for i in $files; do
        run_rc_script $i start

Here's a simple dependency example:

# $NetBSD: timed,v 1.2 2000/03/13 04:04:10 lukem Exp $
# PROVIDE: timed

. /etc/rc.subr


load_rc_config $name
run_rc_command "$1"


Or a more complex on:

# $NetBSD: postfix,v 1.3 2000/04/30 12:21:00 lukem Exp $
# PROVIDE: mail

#       we could do this, but make mail start late, so that things like
#       .forward's are not processed until the system is fully operational

. /etc/rc.subr


start_precmd="checkyesno postfix"
start_cmd="postfix start"

stop_cmd="postfix stop"

reload_cmd="postfix reload"

load_rc_config $name
run_rc_command "$1"


This is really easy to understand and document, and the few people of
all levels of proficiency I've just asked think this is cool.

> - The ports collection is so huge these days that we need to make it
>   easier rather than harder for non-hardcore FreeBSD users to
>   submit and maintain their own ports.  Its already hard enough to
>   do a port right especially if it should have ifdefs on the version
>   of FreeBSD to work correctly in -STABLE and -CURRENT.   Port authors
>   really need -CURRENT and -STABLE installed and maintain a copy of the
>   repository to DTRT.

Most of the ports submitters I know personally only have -RELEASE
machines.  They seem to do fine.

I don't see how the SysV way is any easier than the dependency-based
system.  The dependency-based system means you can set it up, and then
leave it alone and never worry about renumbering.

> - The SysV style number based system is fine in that port authors can
>   all use the same number (say S50myport) unless it needs to be changed
>   due to the unlikely need for ordering (remember we haven't had
> ordering
>   to date and there are ~3700 ports).

This applies equally to a dependency-based system.  Most will use the
PORTS requirement, I imagine, which'd be equivalent to the current
system, and which we could tweak from a central place if needs be,
without changing every single port.

> - Dont think of /usr/local/etc/rc.d being just for the ports collection,
>   people will put there own startup scripts there too and will find it
>   very easy to just pick the right numbers ala SysV.

Only to have the vendor re-number things in the next release, and spoil
their carefully-located numbers?  Dependencies are a big win here too.

All in all I'm delighted with the NetBSD dependency-based system that
has been pointed out to me.  It'd be great to synchronise with their
system, and share and help develop their code (which, from casual
inspection, is great, and looks like it may never need changes).

It kinda makes me wonder what I'll do when I see that RedHat machine at
work. (:

Neil Blakey-Milner
Sunesi Clinical Systems

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to