Toni Mueller <[EMAIL PROTECTED]> writes: > 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.
You should require everything you might use directly using the Should-Start stanza, which says that you should start after those services if anything provides them but that not having them available isn't an error. > 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...). Because modifying a thousand packages in Debian to provide two different init systems (or more -- everyone has their own favorite) is a really good definition of "not fun." We already have a huge infrastructural investment in System V init scripts. > 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. It's better than trying to maintain start sequence numbers, honestly. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
