Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
On Feb 20, Adam Lazur wrote:
> 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.
Then the lsb package would have to be updated to comply with the new
policy anyway, and conflict with versions of file-rc and sysvinit that
did not comply with the new policy.
> 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.
Great, propose a policy change for woody+1, and if implemented then
the lsb package will support it, per policy.
> > 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.
LSB does no such thing. The start_daemon and killproc functions only
do a fraction of what /sbin/start-stop-daemon do. The only way LSB is
better is that instead of using echo, it uses three functions for
success, warning, and failure.
> 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.
RH has higher-level abstraction than this. Even there, "echo" is
still used in their init scripts. For example, let me share the init
scripts for anacron on RH and Debian:
*** RH:
#!/bin/sh
# Startup script for anacron
#
# chkconfig: 2345 95 05
# description: Run cron jobs that were left out due to downtime
# Source function library.
. /etc/rc.d/init.d/functions
[ -f /usr/sbin/anacron ] || exit 0
prog="anacron"
start() {
echo -n $"Starting $prog: "
daemon anacron
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/anacron
echo
return $RETVAL
}
stop() {
if test "x`pidof anacron`" != x; then
echo -n $"Stopping $prog: "
killproc anacron
echo
fi
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/anacron
return $RETVAL
}
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status anacron
;;
restart)
stop
start
;;
condrestart)
if test "x`pidof anacron`" != x; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart|status}"
exit 1
esac
exit 0
*** Debian:
#! /bin/sh
# /etc/init.d/anacron: start anacron
#
PATH=/bin:/usr/bin:/sbin:/usr/sbin
test -f /usr/sbin/anacron || exit 0
case "$1" in
start)
# Really on_ac_power is not a sufficient test, as it only looks at
# APM and we ought to also check whether we're on a UPS battery.
if test \! -x /usr/bin/on_ac_power || on_ac_power >/dev/null
then
echo -n "Starting anac(h)ronistic cron: anacron"
anacron -s
echo "."
else
echo "Starting anac(h)ronistic cron: deferred while on battery
power."
fi
;;
restart|force-reload|stop)
# nothing to do
:
;;
*)
echo "Usage: /etc/init.d/anacron start"
exit 1
;;
esac
exit 0
***
Frankly, I don't see anything more abstract in the Red Hat script than
the ability to localize the messages and the fact that start and stop
are separated out into functions. RH also sources a standard file at
the beginning, which could be used to redefine echo. That's the
extent to which things are abstracted.
LSB doesn't even abstract things that much...
Again, my position is that Debian-wide init functions should be
provided in a Debian core package, or by each init program. Anything
in /usr/lib/lsb, however, should be provided by the lsb package, but
should make use of facilities provided by Debian (including any future
upgrades to the init functionality). That way, you don't have any LSB
cruft on your system unless you want to install lsb-* packages.
Chris
--
Chris Lawrence <cnlawren@olemiss.edu> - http://www.lordsutch.com/chris/
Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
Reply to: