Proposed release goal for Squeeze: Switch to dependency based boot sequencing

[Kel Modderman]

On Tuesday 21 April 2009 02:11:24 Michael Biebl wrote:
> Kel Modderman wrote:
> > On Saturday 18 April 2009 03:46:04 Henrique de Moraes Holschuh wrote:
> >> On Fri, 17 Apr 2009, Michael Biebl wrote:
> >>> Henrique de Moraes Holschuh wrote:
> >>>> On Fri, 17 Apr 2009, Michael Biebl wrote:
> >>>>> I think, one missing piece is a proper interface for updating init
> >>>>> script priorities (if the depencies or the list of runlevel changes) in
> >>>>> a policy compliant way.
> >>>> There is no such interface in this case (if we had one, insserv would have
> >>>> to make it a no-op).  You have to edit the initscript metadata directly
> >>>> (because it is embedded in comment headers on the initscript itself) to do
> >>>> such changes, then tell the system to rebuild the initscript dependency
> >>>> tree.
> >>> How do you do that exactly while preserving local modifications?
> >> The local modifications have to be done on the initscript headers, which are
> >> conffiles since the dawn of time.  The user is warned that by switching to a
> >> dependency-based initscript system, the old order information is deemed
> >> irrelevant and thus completely ignored.
> >>
> >> There is also an override directory that can be used to change the
> >> dependency headers instead of editing the initscript, but we should get rid
> >> of any need to ship files in there as part of the release goal (local admin
> >> can place stuff there as he wishes).
> >>
> >> So, you can have local modifications to the *DEPENDENCY* information in an
> >> override directory.
> > 
> > I'm pretty sure there is a misunderstanding here. An interface for modifying
> > unmodified script properties (such as what runlevels it starts/stops) is
> > desirable for use in package maintainer scripts when a new version of the
> > package wishes to change the scripts start/stop or sequence/dependency
> > properties. That is what Michael is poking us about.
> > 
> > An interface for this was proposed for legacy (aka sysv-rc's) update-rc.d:
> > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html
> > 
> > The discussion went cold after Michael posited that the proposed interface is
> > prone to error because it relies on a human to write out a snippet of shell
> > code in a maintainer script. A similar interface could exist for insserv's
> > update-rc.d. I am without any better ideas at this time.

I had an idea about this issue this week, we should probably discuss this
in more depth when/if we get together in June for the boot performance meeting.

> 
> Yeah, that's pretty much what I tried to say (thanks Kel for the clarification)
> 
> For the record, I don't want it to be understood as I'm against insserv.

It doesn't need to be said, everytime a discussion pops up about Debian boot
system you seem to be in there with stimulating discussion.

> To the contrary: as we are already 95% there, it would imho be stupid to not
> make use of it and reap the benefits (though I still think we need something
> more flexible/dynamic long term, the improvements by insserv are nice for the
> short term).
> I'd even be in favour of dropping the static priorities interface (and file-rc
> for that matter), as it would make our lives as maintainers much simpler.

Yeah, I share those same sentiments.

Thanks, Kel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20090426/b96ae0d0/attachment.htm>