Re: Please all dependency info into your init.d script
On Fri, 06.07.2007 at 22:43:31 +0200, Petter Reinholdtsen <email@example.com> wrote:
> As you might be aware, there are several bugs in the Debian boot
> sequence. The bugs affect some combinations of packages, and are some
> times hard to solve. To solve them once and for all, I want us to
> switch to a dependency based sequencing of the symlinks in
> /etc/rc*.d/. I gave a talk about this at Debconf, see
> <URL:https://penta.debconf.org/~joerg/events/21.en.html> for the
> slides and more info.
Packages may or may not require services, depending on actual runtime
configuration. Eg. roundup can use one or more out of a number of
database mechanisms, some of which require external SQL servers, and at
least one that doesn't. Request-Tracker may be run at least with MySQL
or PostgreSQL, so require which? What if the configuration specifies
one while a "virtual service" $sqldatabase (purely fictional) might
provide only the other? Should we require both? Slapd may require an
external SQL server if a suitable backend is defined, and I guess that
a whole slew of other applications have similar problems.
To me, the one big question is why you want to stick with the SysV init
script system instead of eg. switching to runit (my personal favourite,
w/o having looked far, yet - but it's hard to get worse than SysV
IOW, I'm very doubtful that adding this new complexity really solves
the problem instead of (maybe) making it even worse - worse, because
the limited usefulness is now offset by increased changes for packaging
errors and maintenance burden.
I suggest that we take a step back and first examine the field and
determine a solution instead of rushing to action with SysV init (for
no perceivable gain, imho), and if I can wish something for Lenny right
now, dropping SysV in favour of a better alternative is high on my
> <URL:http://wiki.debian.org/LSBInitScripts> for clues on how to write
> such header.
I've read that as well, but could not find an answer to my questions
Thank you for listening!