Subject: Re: take 2; which way should we go for /etc/rc...To: None <tech-userlevel@netbsd.org>From: John Nemeth <jnemeth@victoria.tc.ca>List: tech-userlevelDate: 12/08/1999 02:58:30

On Dec 2, 11:03am, Luke Mewburn wrote:
}
} I see the following options for implementation. We should choose one
} of these, and possibly ship with the ability for a user to switch to
} another if they so desire.
}
} a) Do nothing
} Pros:
} - nochangeniks like it
I wouldn't call myself a "nochangenik", but I don't like change
just for the sake of change. If something changes there must be a
demonstratable benefit.
} Cons:
} - hard to control daemons post boot (without examining
} /etc/rc to see how something was started)
I don't find this to be a problem, but then I've been admin'ing
UNIX for 10 years (more if you count my days with Minix), so I have all
the options memorised anyways. However, I do see how this could be a
problem for newbies.
} b) /etc/rc is autogenerated from /etc/init.d at some stage
} (possibly by the developer who last changed an init.d
} script).
If we have to change, this is the option that I prefer, combined
with some method of handling "standard" thirdparty scripts.
} d) /etc/rc runs /etc/rc3.d/S* in filename order. (rc.sysv.sh
} implements this). /etc/rc3.d is created from /etc/init.d by
} running `mkrc -s01` once.
} Cons:
} - considered to be an ugly warty sysvism by a lot of
} people
Yep.
} - if 3rdparty scripts are to be integrated into the
} mkrc phase they need PROVIDE/REQUIRE lines.
I don't think this is particularly onery since they already have
to worry about whether the system uses two digits or three digits,
where the directories are (on HP-UX they are in /sbin), and what the
default run level is.
} e) /etc/rc is autogenerated from /etc/init.d/ containing a list of
} lines which just do "/etc/init.d/foo start; /etc/init.d/foo2 start",
} etc.
} Cons:
} - have to regen /etc/rc if /etc/init.d is updated.
Add, very slow.
} f) Full SYSV style run levels.
} Pros:
} - don't know
} Cons:
} - does it really win us anything.
} - This is BSD.
Yep. If NetBSD starts down this path, then I (and probably
others) will be looking at switching OS'es. One of the big reasons
that I use NetBSD is precisely because it is BSD. rc.conf is a nice
improvement over the standard rc since it makes it easy to turn things
on and off and configuration is centralised (one of the things I really
hate about SysV is how configuration information is spread all over the
place). Going to that really ugly SysV method would be a major step
backwards. For those that want SysV, they know where to find it.
} [There's probably other options I've missed as well.]
}
} The questions are:
}
} 1. Which method do we ship with enabled by default?
} I'd argue for b) or c), possibly supporting d) or e),
} and strongly against f).
See above.
} 2. Do we support the other methods (e.g sample scripts in
} /usr/share/samples/rc/) such as rc.sysv.sh if we choose
} rc.sh.
} I'd say `yes', because there's no real harm in
} giving people the choice.
I don't really see the point in this since it could lead to
problems with support (both internal to organisations due to differnt
admins doing things different ways, and external), but I don't have any
really strong objections to it.
}-- End of excerpt from Luke Mewburn