Re: Debian boot system
On Sat, Oct 07, 2000 at 03:17:35PM +0200, Eyal Lotem <eyal@hyperroll.com> was heard to say:
> On Sat, 07 Oct 2000, Henrique M Holschuh wrote:
>
> > > No. You need to create a Makefile, that can be SEPERATELY and
> > > INDEPENDENTLY
> >
> > No, "separately and independently" management will cause you problems. What
> > I mean to say is: You only have available the update-rc.d interface (and,
> > if I have my way with Debian's initsystem, you'll have a start-rc.d and
> > optional policy-rc.d interfaces as well, but that's a matter for another
> > post when I finish testing the code), and you must be able to migrate from
> > one init system to the other. Please look at the file-rc package to see how
> > its done.
> Ok, I have a simple solution to it then :)
> The Makefile itself contains all the information and dependencies, and really
> shouldn't be larger than some dozens of K's, at worst. This Makefile can be
> kept on all systems, and be the actual source of information about the bootup
> system. This Makefile could be maintained by a simple script that parses it
> and updates its dependencies/rules.
> This makefile will have rules for each runlevel, specifying which subset of
> services/etc should be started for that runlevel.
> To run the actual init.d scripts from the Makefile, you would use an
> overrid'able variable in the Makefile, that under normal circumstances
> (normal make-booting), would run the scripts, whereas under sysVinit system
> generation, would output the command to run, with an increasing preceding
> number, to identify its location in the order of the boot. (such as
> S20isdnutils S21proftpd S22... etc)
>
> To create the traditional System V system out of that Makefile should be
> fairly simple. All you do is run make on the Makefile, with the
> running-command variable overridden to just print out the names of what to
> run, and you use this output to generate the symlinks pool.
This is a nice and elegant solution, but I don't think it'll work.
The problem is that packages which register themselves with update-rc.d
generally (as far as I know) count on the other packages in the system
having the same (default) numerical priorities so that everything happens in
the same order. An autogenerated ordering will break this. (it won't be
an immediate issue..I think..since the main effect will be to compress the
boot numbers (so newly installed packages will still be started after
their usual dependencies), but I would want to think very hard about this
before declaring it to be safe)
Of course, if this were to someday become the primary Debian boot
mechanism, I don't think that would be an issue, but I think that for now,
you have to deal with legacy code nicely..
Daniel
--
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
| He had a terrible memory. He remembered everything. |
\---- Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Reply to: