Hi,
I don't know if I got it wrong, but AFAIK runlevels work this way in
Gooch's simpleinit:
A runlevel is just any script whose name makes it being called by
/sbin/init on a certain runlevel, like
/etc/init.d/runlevel.3
There is nothing special about this script, it could do anything you
want. Usually I think it will only print out messages like "Dude, this
is runlevel 3" and <need> all the packages that should be started in
runlevel 3. It may have the line "need runlevel.2" at the beginning, but
thats totally optional. You could also make runlevel 3 build upon
runlevel 4, or none at all, or even make it dependant on something (eg
runlevel 5 starts either runlevel 2 or runlevel 3, depending on whether
it is started on weekends or on regular days).
And of course runlevel.6 could be some shutdown script and just tell
simpleinit to rollback all other scripts, or it could be handled as a
special case inside /sbin/init.
A No-Op /sbin/need would probably the way to go, since it is easier to
do than a
test -x /sbin/need || need somescript
in every package with a /etc/init.d script (easier, that is less
packages to files bug against). Henrique, what do you think about this?
I think if it is possible to include and support different (even
completely different) startup ways in debian, this is very desireable.
There are hughe advantages in each and every singe scheme available at
least for specific users. For example the transparent way simpleinit
support an arbitary number of startup configurations (instead of just
runlevel 2-5 and maybe 7,8,9), since a runlevel is just a way to select
the startup script.
Dependecy informations in script comments are a bad idea:
* You are limited in type of script (shell, perl, C, vbs) you want to
use.
* You can't use dependency conditinal, like in:
if any remote file systems are to be used via an interface that is a
ppp device, than depend on pppd unless the file system is marked noauto
or the target host is already pingable for some strange reason
Ok, the example is bad, but having laptops and other mobile devices
in mind, that have to be very flexible in a lot of ways, this is an
advantage.
I am really not trying to replace the sysvinit scheme as a default one,
and I don't think anybody else is. But having the option to use a
different one is a goal worth going for.
Joachim
Am Mon, 2003-04-28 um 00.44 schrieb Theodore Ts'o:
> One big problem about Richard Gooch's simpleinit is that it is
> functionally very different from the standard systme V init scripts.
> Specifically, he always assumes that runlevel n+1 is always a superset
> of runlevel n, and that in order to get to runlevel n+1, you must
> first start up all of the services at runlevel n.
>
> Runlevel 6 has been used for "reboot" since time immemorial, and in
> fact is documented in Debian Policy as such. Simpleinit can't support
> this.
>
> > * The /etc/init.d/ scripts would need to add "need otherscript" (and
> > sometimes "provide something"). As I think it is a very bad idea to edit
> > these scripts in our post-install (and try to reedit them in
> > pre-remove)) one would have to file bugs agains packages with
> > /etc/init.d scripts. Will that be sucessfull? How cooperative will the
> > maintainers of these script be?
>
> And just adding "need otherscript" and "provide otherscript" will
> break compatibility on systems that don't use simpleinit, unless the
> system V initscript package is enhanced to provide no-op functions
> which provide "need" and "provide".
>
> > * Is there even interest in simpleinit by others than me? I would also
> > need someone to ask if I have problems with sysvinit or similar, and I
> > would like to know who thinks he is capable of helping me? Are there
> > people that might help me when it comes to file bug against packages
> > with /etc/init.d scripts?
>
> Simpleinit is unfortunately completely incompatible with System V
> init. So at the very least, Debian Policy would have to be amended to
> support simpleinit, and I'm not really convinced it's really worth it
> for Debian to support two fundamentally different init script systems.
>
> Not only are the init scripts different, but the interface which is
> exported to the system administrator, and what can and can't be
> implemented using simpleinit, is completely different.
>
> For this reason, I consider simpleinit to be a failure and a mistake.
> With a little bit more work, for example, the traditional system V
> runlevels could be implemented, and the dependencies could have been
> implemented in a structured comment block, for full backwards
> compatibility. I've been told that SuSE's init scripts system does
> this, while also providing full automatic dynamic dependency
> management, ala simpleinit. I haven't had a chance to look at it, but
> everything I've heard about it makes it sound far better than
> simpleinit.
>
> - Ted
--
Joachim Breitner
e-Mail: mail@joachim-breitner.de | Homepage: http://www.joachim-breitner.de
JID: joachimbreitner@amessage.de | GPG-Keyid: 4743206C | ICQ#: 74513189
Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil