>>>>> "Dave" == Dave Sherohman <[EMAIL PROTECTED]> writes:
Dave> It's not that symmetric, I'm afraid. <snip> Dave> Worse, though, is the case of a binary-only package which makes Dave> assumptions about running services based on runlevel. When it Dave> breaks because of customized runlevels, the admin _can't_ fix it Dave> except by going back to the LSB-defined scheme. Certainly, this is bad, however I imagine that altering the LSB specification to forbid this sort of idiotic behavior, and saying that the runlevels are defined for the sole purpose of determining which runlevels to insert boot scripts into, and that relying on checking the runlevel is an error, would be well-recieved, whereas just chucking the whole thing, will not. Certainly, you have made an excellent case for the default runlevels being an "installation only" tool. Dave> Code which depends on having certain services running should Dave> check for those services directly. (Reality check: It still Dave> needs some sort of equivalences database to do this, so it can Dave> recognize that, e.g., a dependency on xdm is also satisfied by Dave> wdm, gdm, kdm, etc. Package dependencies for runtime services Dave> instead of for installation, basically.) If a universal Dave> runlevel scheme is standardized, developers will come to rely on Dave> it, simply because it's that much easier than checking the Dave> services individually, and things will break if deviate. Dave> Establishing this dependency serves no purpose other than Dave> creating another unwise shortcut for developers to take. I disagree. Starting X may involve starting multiple services, xdm, xfs, it's certainly possible you don't want sound daemons running, unless you've switched into "workstation mode". Certainly, grouping together networking services (potentially a great many services) into a runlevel makes sense. Certainly, a network daemon should not be installed into a runlevel which doesn't ifup any interfaces. While the defaults may not deal with every possible use for runlevels, they do make some sense. Certainly, an LSB 2 with an entirely new system for handling init, that has full dependency and pseudo-package (gdm/xdm/etc) support would be an exciting thing. Right now, we have runlevels. Dave> As others have pointed out, the RH/LSB 'runlevel exists Dave> primarily to control X' tendency doesn't always make sense - Dave> laptops may use them to help manage power/performance tradeoffs, Dave> some machines don't have xdm (or even an X server!) installed, Dave> etc. Well, there's also the networking/no networking distinction. Dave> Also, elsewhere in this thread, I saw a statement about Dave> switching between runlevels 3 and 5 on a RH system all the time Dave> to, essentially, toggle xdm. This was followed by a complaint Dave> about this being a much more involved thing to do in Debian, Dave> which strikes me as absurd. `/etc/init.d/xdm stop|start` might Dave> call for a little more typing than `init 3|5`, but it's hardly Dave> difficult. And, to me at least, `xdm stop` obviously means Dave> "shut xdm down", while `init 3` has no readily apparent Dave> relationship to X or xdm unless you're bringing outside Dave> knowledge with you. Agreed. Assuming, of course, you don't run xfs or rplay, or anything else you want running with X. In which case it does make sense to group those things together. The only mechanism we have now in init, is runlevels. -Eric
