[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: