Re: Switching the default startup method
Hi, Steve:
On Monday 24 August 2009 09:19:28 Steve Langasek wrote:
> On Mon, Aug 24, 2009 at 08:38:21AM +0200, Andreas Barth wrote:
[...]
> > Eh. This translates to: "it is ok that the admin cannot switch back
> > from insserv to oldstyle booting".
> >
> > And that is a statement that I heavily disagree with. I think neither
> > our users nor our developers at large considers that a feature, but
> > rather a very grave bug.
>
> I don't presume to know what the majority of developers think about this,
> but *I* think the traditional sysv-rc boot system is broken beyond repair.
> I am not at all concerned with giving users infinite choices in their boot
> systems - I think there should be exactly one, which should be bug-free.
>
> > We should definitly continue to support oldstyle booting, at least for
> > the time being.
>
> Why?
>
> So far, the only bugs that have been highlighted in this thread appear to
> be bugs that happen when trying to remove insserv. If there aren't any
> problems with the new system, why do we need to support downgrading?
It is not "downgrading" but certainly an structure that has been there for
whole decades. It is *the* expected way (not meaning that a better way won't
be gladly accepted but that for quite some time it will be the "new" thingie,
not the "standard").
It is quite within "the unix way" to follow the "least surprise principle".
For most admins over there (i.e.: me) the new dependency-based init process
will be a "let's try and see"; it certainly will come to a great surprise
knowing after the fact that there's no rollback path. Following this trend
the best you could do is advertising in big bold letters on the release notes
that there's no way back from insserv but for concious and busy admins that
will mean not the time to try the new thingie now which in turn will mean the
subtle nasty bugs won't be rised.
Even after decades there're still are problems on the init sequence hard to
address *even* on a case by case basis by the local admin (i.e.: LVM local in
order to mount root but then LVM failing on SAN volumes because network is
still not ready). Be ready to discover subtle and nasty bugs on any
dependency-driven init process as soon as it starts being widly adopted. Not
having a rollback for those that find it the less troublemaking path seems to
be not a wise decision.
I'd say that two stable releases where sysv-rc and insserv should cohabitate
and there's guaranteed chances to go back and forth between them is the
conservative option.
> > So you are telling us here that anyone who depends on the 20+ years
> > working method of ordering boot with decimal numbers is using a
> > regression? Sorry, but this is just plainly wrong.
>
> Not really. There are longstanding bugs with the sysv-rc approach that are
> never going to be fixed except by migrating to a new system designed with
> these problems in mind.
Which in turn will bring its own lot of bugs too.
> The fact that symlinks have to be changed by hand whenever one daemon gains
> a dependency on another, possibly in cascading fashion, is one such bug.
>
> I have seen that insserv does still have some rough patches at the moment,
> and I think these are documented in the BTS and I have every confidence
> that they will be addressed. But I think "insserv doesn't permit removal"
> is the least important of these.
Maybe on squeeze+2, not now.
Reply to: