|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:
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.
> > Do you propose maintainer scripts should add special case code for insserv?
> I don't think that would be needed. During a dpkg run, a single insserv run
> at the end of the dpkg run should be scheduled (if insserv is active) via
> the dpkg triggers and also by any calls to update-rc.d (which will just
> schedule the insserv run, really), as well as changes to /etc/init.d/* and
> the insserv override directories.
Actually, I do not believe it would be good to have insserv run on a
dpkg-trigger, that could potentially open the door for larger problems than
can occur when each script is inserted individually at package postinst time.
In the latter case, if an error occurs it is due to only one script
addition/modification and the problem is more easily rectified.
> Nobody said anything about getting rid of non-dependency-based boot for
> Squeeze, BTW. We should aim to make dependency-based (and if at all
> possible, parallel execution) perfect, and the default... but not the only
> option, at least not yet. Maybe for squeeze+1 or squeeze+2.