Re: Bug#325234: debian-policy: mention if coincidence runlevels 2345 all same
On Fri, Sep 02, 2005 at 11:45:47AM +0200, cobaco (aka Bart Cornelis) wrote:
> On Thursday 01 September 2005 18:26, Andrew Suffield wrote:
> > On Thu, Sep 01, 2005 at 02:03:27PM +0200, cobaco (aka Bart Cornelis)
> wrote:
> > > but is there really any good reason to have the default run-level
> > > states differ from the LSB defined init-level states [1]?
> >
> > Is there any good reason for changing them from their current one?
> > "Because the LSB says so" is not a reasonable answer;
> we're talking about a _default_, not about declaring that users can't set up
> each runlevel how they like.
What's the use of a default anyway?
> Given that changing the default does not keep our users from setting up
> runlevels exactly how they like. I don't see how differing from the LSB
> gains anything.
I don't see how it gains us anything to move away from what we've been
doing for ages.
> On the other hand it does make sure that a lot of non-distro specific
> documentation matches the default situation on Debian also.
What's the use of non-distro specific documentation about system
administration anyway? If you install a Debian system, you should have
Debian-specific documentation.
Of course, that doesn't mean all documentation has to be
distro-specific; but if you document things that are likely to be
different across distributions, then it makes no sense _at all_ to try
and create documentation that is distribution-agnostic. And system
administration is _very_ likely to be different across distributions.
> -> I can see a dubious[1] advantage to our developers as it means less work
> -> I _don't_ see any advantage to our users for sticking with the current
> default while I do see a clear disadvantage as mentioned above
I am not convinced that changing to predefined default runlevels is
going to gain us anything:
* If, as you say, they're meant to be defaults (and just that), then it
shouldn't matter whether they're kept as is or changed. In any case,
packages should not assume that the runlevels are as they are thought
to be by looking at the LSB spec. This, then, would make one wonder
why they're there at all -- there's no obvious gain for packages.
* 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. 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 doesn't help users either. 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.
Debian has always been about 'doing it the right thing'. I don't think
that having ugly defaults is 'the right thing'.
Having the rest of the world jump into a pit shouldn't mean that we
should, too.
[...]
> > Debian is not an LSB system.
>
> true at the moment, LSB-compliance for the init scripts is on the TODO list
> for etch though,
What TODO list? Not mine at least.
> and having Debian being LSB-compliance would be a boon for
> getting corporate support for Debian (e.g. it's an explicite goal for the
> DCC)
If LSB compliance requires us to implement braindead and ugly things,
then fuck the LSB.
> > We use Debian packages and not LSB ones, for starters. And
> > the spec clearly says that these numbers are just for arguments to the
> > install_initd LSB command, not application use. Our install_initd,
> > assuming the LSB compatibility stuff has one, can simply remap them.
>
> The spec contains the following:
> Note: These run levels were chosen as reflecting the most frequent
> existing practice, and in the absence of other considerations,
> implementors are strongly encouraged to follow this convention to provide
> consistency for system administrators who need to work with multiple
> distributions.
>
> Exactly what are our other considerations?
See above.
> > Our defaults are certainly easier to understand and remember. They
> > have clearly defined, non-vague meanings.
>
> yeah, all run levels is the same _is_ easier to remember then this runlevel
> does that and that runlevel does this
>
> It's not a very usefull default though, if they all do the same thing anyway
> way bother making the distinction?
Defaults don't need to be useful. They need to be (a) generic and (b)
working. That's what ours do.
[...]
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: