Re: [users] Re: Time to fight for our beloved DEB format!
On Wed, Jul 04, 2001 at 12:05:12PM +0100, Eric E Moore wrote:
> Ok, you don't define runlevels, admin with nonstandard runlevel scheme
> (runlevels meaning different things) has to move scripts around after
> software installs. You do, and guess what? an admin with nonstandard
> runlevels has to move scripts around, and manually manage her
> runlevels. If she doesn't use the LSB ones, she won't be able to
> install LSB packages without manually handling the boot scripts.
> 'course, if the LSB says nothing about where they go, she has to
> manually fiddle the boot scripts.
It's not that symmetric, I'm afraid.
If you don't define runlevels, admins may have to shuffle links to
arrange things like they want, but that's it.
If you do define runlevels, application programmers (a notoriously
lazy bunch - which is not necessarily a bad thing, but many are prone
to taking unwise shortcuts) are likely to rely on them. If a
non-init script checks the runlevel to determine what services are
running, it will break if the relevant init scripts have been moved
or if an admin has manually started or stopped a service for some
reason. The admin then has to find the script and modify it to
behave properly.
Worse, though, is the case of a binary-only package which makes
assumptions about running services based on runlevel. When it breaks
because of customized runlevels, the admin _can't_ fix it except by
going back to the LSB-defined scheme.
Code which depends on having certain services running should check
for those services directly. (Reality check: It still needs some
sort of equivalences database to do this, so it can recognize that,
e.g., a dependency on xdm is also satisfied by wdm, gdm, kdm, etc.
Package dependencies for runtime services instead of for installation,
basically.) If a universal runlevel scheme is standardized, developers
will come to rely on it, simply because it's that much easier than
checking the services individually, and things will break if deviate.
Establishing this dependency serves no purpose other than creating
another unwise shortcut for developers to take.
> Dave> (Much the same situation as with people who respond to questions
> Dave> about 'how do I get rid of this GUI login screen?' by saying
> Dave> 'change to runlevel 2' - they're making assumptions about what
> Dave> each runlevel means. Even on a RH system, it's not guaranteed
> Dave> that rl5 = X and rl2 = not X. The admin might have shuffled
> Dave> symlinks because he wanted it the other way around.)
>
> And someone not the sysadmin (who knows what he did) is changing the
> runlevel why? And how?
I was referring to all the people I've seen in various online fora
(including the debian-user list) asking how to enable or disable GUI
logins and being told to change into/out of runlevel 5, which I only
know to be accurate on a stock Red Hat install. (Given that it is
known to be inaccurate for a default Debian install, I have no idea
why that answer would be given on debian-user, but I've seen it here
more than once.) So it's not a third party making the wrong runlevel
change, it's a third party telling the admin to change it.
As others have pointed out, the RH/LSB 'runlevel exists primarily to
control X' tendency doesn't always make sense - laptops may use them
to help manage power/performance tradeoffs, some machines don't
have xdm (or even an X server!) installed, etc.
Also, elsewhere in this thread, I saw a statement about switching between
runlevels 3 and 5 on a RH system all the time to, essentially, toggle xdm.
This was followed by a complaint about this being a much more involved
thing to do in Debian, which strikes me as absurd. `/etc/init.d/xdm
stop|start` might call for a little more typing than `init 3|5`, but
it's hardly difficult. And, to me at least, `xdm stop` obviously means
"shut xdm down", while `init 3` has no readily apparent relationship to
X or xdm unless you're bringing outside knowledge with you.
Reply to: