On Wed, Jul 04, 2001 at 03:35:17PM +1000, Anthony Towns wrote:
> Why are runlevels specified? If I choose to run a system that doesn't use
> runlevels, why should ISV's software break? If I choose to give different
> meanings to the first 6 runlevels, why should ISV's software break?
More additionally than relatedly, but the facility names section doesn't
seem entirely clear either.
If I have scripts /etc/init.d/foo and /etc/init.d/bar in my .lsb
package (with names allocated by LANANANANANA [0]), can I just put a "#
Required-Start: foo" in bar, or do I also need a "# Provides: foo" in foo?
Are facility names allocated by LANANA? Am I meant to use
# Provides: azure.humbug.org.au-foo
if I need to make up names on my own? Or what?
The LSB spec says:
``LSB applications should not provide system facilities.''
then goes on to list the system facilities, and then says:
``Other system facilities may be defined by other LSB applications.''
Is the latter meant to be "Other system facilities may be defined by LSB
distributions" ? Or what?
Depending on $local_fs and $remote_fs doesn't seem entirely meaningful. If
a script needs /usr mounted before it can be run, presumably it should
always Required-Start: $remote_fs. Does $local_fs let you assume
anything more than that /bin, /etc, /sbin, /lib and /tmp are available
for read access?
If this is meant to work for non-Linux systems running some Linux
compatibility mode, then it's likely that some LSB systems won't be
able to run LSB programs at all in single user mode or without /usr or
similar. If that's the case, then an LSB distribution could reasonably
only run LSB init scripts after everything else has already been started
(trivially satisfying any Required-Start dependencies on system services).
Would that be bad? It'd mean you couldn't make an LSB package that
automagically ran daemons to help you do something-or-other in single
user mode, and similar. There's probably not much useful you can do
there anyway, though, since you can't have LSB-compliant kernel modules
and stuff.
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.
Is there any practical benefit to providing a "cleverer" implementation?
Cheers,
aj
[0] To the tune of "Deck the halls"
--
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:
pgpiBWCFtorzm.pgp
Description: PGP signature