On Thu, Jul 05, 2001 at 11:55:04PM +1000, Anthony Towns wrote:
> So. In summary, it seems like you can just start LSB init scripts after
> you've upped the network in any random multiuser runlevel (even ones
> that don't run xdm), ignore any system facilities listed (since they're
> all handled already), ignore any possible relationship to distributor
> provided scripts (since they're not guaranteed to be there anyway),
> and just take care of any inter-dependencies amongst LSB packages.
Which basically means having
/etc/rcN.d/S99lsb
which then runs various stuff from, say,
/etc/opt/rcN.d/S*
This has the drawback of not letting user tools written to cope with
/etc/rcN.d manage LSB init scripts very well; and if the user uses a
different init script method (which they can in Debian with out much
trouble) ending up with LSB init scripts managed by symlinks while
everything else is managed by a file.
Implementing things the other way has other problems. If you have, say,
10 S-levels to play with, say S70-S79, how do you assign them without
knowing what future LSB packages you might install? No matter what you
do, you can obviously allocate the numbers suboptimally. So the obvious
solution is to allow install_init to rearrange init scripts it's already
installed if it decides it needs to. Which is entirely doable.
Where the problems occur, though, is if the user comes along in the
meantime and starts messing with the symlinks the various scripts
have added in /etc/rcN.d. Somehow install_init needs to balance the
requirements of installing the new init script and preserving the user's
changes. Even telling that the user's made a change may be difficult if
the change was limited to changing the order of the scripts: especially
if the change was relative to vendor provided init scripts rather than
ones from LSB packages.
By segregating LSB init scripts into /etc/opt/rcN.d/ you can at least
give install_init complete knowledge about what's going on, and make it
go to some lengths to ensure that you at least keep the user's preferred
order of init scripts maintained. That seems like it wouldn't be a very
effective integration though.
Any advice from the LSB spec team would be appreciated...
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpR63DcE_IZK.pgp
Description: PGP signature