Re: [users] Re: Time to fight for our beloved DEB format!
>>>>> "Dave" == Dave Sherohman <esper@sherohman.org> 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
Reply to: