[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with init



Perry E. Metzger wrote:
> 
> "Joel Baker" <lucifer@lightbearer.com> writes:
> > Is there some reason that we can't, at least for the moment, just hack
> > around init such that the scripts it *calls* call into /etc/rc<x>.d (and
> > thus, to /etc/init.d)? Simulating SysV init scripts shouldn't be that
> > difficult; while I have been told that some inits (notably FreeBSD's) don't
> > support all of the runlevels, this could be fixed much more easily, either
> > upstream or locally, than trying to port over glibc...
> 
> NetBSD has an rc system that was designed by Luke Mewburn based on
> some ideas of mine (and a program I wrote called rcorder). Rather than
> having the files in the rc?.d directories run in a lexically defined
> order, they run in a dynamically computed order based on
> dependencies. This works a lot more nicely and is pretty logical. We
> switched to the system a while ago.
> 
> FreeBSD is now (I understand) adopting our system.
> 
> I strongly suggest studying it before throwing it out. Simulating SysV
> init script behavior is pretty trivial in our system, except for the
> fact that we don't have run levels. We decided that in practice people
> don't actually need or use run levels although they very often claim
> to want them.
> 
> Perry

This brings us back to Debian-Policy, which is quite explicit about what
must be done by init (though, thankfully, it doesn't declare *how* it must
be done). Please see the Policy Manual, section 10. Unless we intend to
move all of Debian to this init (hey, if you think it's that much better,
convince them), runlevels it is. At least if this is going to be called
Debian. Me, I happen to like SysV init, but I agree, simulating it should
not be terribly difficult, and should suffice to meet the requirements of
the Debian Policy.

I do think it's important, at this stage, simply for the fact that working
around it for the time being would allow us to avoid the problem of glibc
for a while longer (and, honestly, I'd rather use the native libc anyway,
if we can manage it). Looking at what it will take to meet Policy is, in
my opinion, *not* something we should be putting off, when it raises a
relevant question, unless we want to have to go back and rework half of
the core system.

But hey... just my suggestion for the "KISS" solution.
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://www.lightbearer.com/~lucifer



Reply to: