Re: Bug#325234: debian-policy: mention if coincidence runlevels 2345 all same
On Fri, Sep 02, 2005 at 05:02:10PM +0200, cobaco (aka Bart Cornelis) wrote:
> On Friday 02 September 2005 14:58, Wouter Verhelst wrote:
[...]
> > * We won't be able to change them on already running systems
> > automatically: there are so many initscripts that it's very likely at
> > least one will have been changed. As a result, you can't just go ahead
> > and change their symlinks.
> I'd wager that most normal users (as opposed to developers) have never
> changed an initscript.
I should've been more clear, but I actually meant the symlinks to them,
rather than the scripts themselves. Those _will_ have been changed
sometimes.
[...]
> - It shouldn't be to hard to convert a system over to LSB-runlevels if the
> runlevels and initscripts haven't been changed.
True. But, again, I consider it fairly unlikely that 'most' systems have
had their symlinks unchanged.
> - If any init-scripts /runlevels have been changed then the setup on that
> system is non-default, and it's likely a fair assumption that it's setup
> exactly how the sysadmin wants.
False. The sysadmin(s) may have unadvertently made an error. They
could've just fixed this little thing which they considered an annoyance
in their situation, but not necessarily a bug. They might have installed
some program without making use of the package manager, which installed
symlinks in /etc/rc* -- and those are /completely/ obscure to us. A
buggy package could have registered an initscript incorrectly.
There are many ways in which the system configuration could've changed
without making the assumption that the maintainer knows what he's doing
and doesn't want it to be migrated correct.
> Which means we don't have to (and shouldn't) mess with it at all
> This really is no different then any other default config change in Debian
> were we change the config file if it hasn't been changed. In this case it's
> not an actual file, but it's still default configuration.
Exactly my point. But it is /also/ my experience that there are
sometimes more or less false positives of such things.
> > Since you don't know what the repercussions
> > will be if you change /some/ symlinks, but not all of them, you can't
> > just go ahead and change those. So if we ever implement it this way,
> > we'll end up in a situation where the documentation will have to say
> > things like "If you installed the system as Debian 3.2 or later, then
> > you'll see <foo>. If you installed it before that time, you /might/
> > see <foo>, but it's also very likely you'll see <bar>." Not only is
> > that very ugly, it's also very confusing.
>
> It's documentation referring to the default state, if you've changed the
> default state that documentation can't be relied on anyway, If you haven't
> changed the default state conversion shouldn't be a problem (we make
> changes in that case for other configuration, I don't see how this is any
> different)
> -> non-issue
>
> > * It doesn't help users either.
> at the very least it makes more documentaton and troubleshooting tips apply
> which is a plus.
>
> > One assumption one can make is that if you don't want something (say,
> > KDM), you don't install it. This (reasonable) assumption is true on
> > Debian; it is not true on RedHat or others. Worse; if you want X (but
> > don't want XDM), you can't even uninstall it even if you would like to do
> > that. Also, you'll have to be taught how to disable something in a config
> > file that you may or may not have heard about, and which also has the
> > potential to break your entire system if you do it wrongly.
> how's this relevant to Debian-default runlevels differing from LSB-default
> runlevels?
They differ from the LSB-default runlevels because the LSB-default
runlevels are silly and broken.
If you want us to move to something else, not only should you have
arguments to convince opponents; you should also be prepared to see
arguments for the status quo. This is one.
I still think it's better for users if they have a canonical way to
disable /any/ service -- removing it from the system.
> If anything this tells you exactly why Debian shouldnt differ from the
> standard unless we have a real good reason.
>
> > Debian has always been about 'doing it the right thing'. I don't think
> > that having ugly defaults is 'the right thing'.
> the LSB default is not any uglier then the current Debian one, on the
> contrary:
We disagree, then.
> In debian the distinction between runlevels 2-5 is completely
> useless (and thus confusing: why do we have these 4 runlevels if they're
> the same anyhow, that just makes it more complicated).
We have those runlevels because init has the ability to have more than
one runlevel. Just because something is possible doesn't mean it has to
be shipped with that possibility being used.
Most systems I've seen don't use the 'other' runlevels ever, either.
Even if they're configured differently.
Besides, give me one good reason why you would want to run any daemon,
besides a desktop manager such as gdm or kdm, /only/ when X is running?
What's the use of a whole different runlevel if all you're running under
that runlevel differently is your desktop manager?
[...]
> > Defaults don't need to be useful. They need to be (a) generic and (b)
> > working. That's what ours do.
> How does having 4 exactly identical runlevels help our users do anything?
How does having 4 different runlevels help our users do anything? We
don't need to have predefined runlevels just for the sake of it!
> Making a distinction between 4 things that are exactly the same isn't
> exactly my definition of 'working' even if it doesn't break anything
They work as advertised. They way they are advertised just happens to be
different from what other people are doing. That doesn't mean those
other people are right.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: