Hi, On Fri, 06.07.2007 at 22:43:31 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 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 init, so...). 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 list. > <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 there. Thank you for listening! Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
