Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
Chris Lawrence (lawrencc@debian.org) said:
> > This would ease addition of an alternative package that provides init in
> > the future.
>
> Actually, they use the defined interface to init, so they should work
> with any init that supports update-rc.d (per policy). The readme may
> be overspecific on this point by referring to sysvinit.
update-rc.d is SysV init specific.
So by including {install,remove}_initd in the lsb .deb and using
update-rc.d, Debian systems are limited to using Sys V init.
If you put install_initd and remove_initd in the actual package that
provides init, then another init system could easily plug in by
providing the lsb interface and _not_ the update-rc.d interface. (yes,
this would require removing update-rc.d from policy and making the
official way of adding an removing a bootup script to be the LSB way)
If you're not getting what I'm hinting at, I'd like to move away from
crappy SysV init and use something better in the future.
The LSB defining a sane way of genericizing init script installation and
removal without adding SysV inspired braindamage is a glimmer of hope
that one day I'll be able to use the NetBSD rc.d system [1] or Linux
boot scripts [2] with Debian, both of which suck substantially less than
SysV init.
> Well, ideally init-functions should call some nice pluggable stuff for
> the output logging, if we come up with an init logging policy for
> woody+1 (it's been talked about, but nobody to my knowledge has said
> "I have an implementation" that we can play with).
That's cool, as long as it's easily replaceable with a custom version.
Read on...
> My gut feeling is that init-functions *itself* should stay in the lsb
> package, because it has to conform with LSB practice. I really don't
> think it's a good idea for $random_debian_package to use the LSB
> interface, as it's pretty lame compared to start-stop-daemon.
I guess our views differ there.
IMO it's pretty lame that everybody rolls their own init script and adds
their own personal bugs when simple things like starting and stopping a
daemon could be centralized (like the LSB does). IMO it's also pretty
lame that any maintainer can spew data to the bootup screen in any way
they see fit.
The LSB functions allow for all of that stuff to be centralized and
stardardized. This is good. It makes everything behave the same way. It
also has the bonus of allowing replacements that conform the the API but
do things intentionally differently.
For example, RedHat has this sort of abstraction in their init scripts.
This allowed Sun to easily override those functions with ones that
display the startup status on the LCD of a cobalt box. This currently is
pretty near impossible to do on a Debian system, but it really shouldn't
be.
--
Adam Lazur, Cluster Monkey
[1] http://www.daemonnews.org/200108/rcdsystem.html
[2] http://www.atnf.csiro.au/~rgooch/linux/boot-scripts/
Reply to: