<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans Mono'; font-size:9pt; font-weight:400; font-style:normal;">On Saturday 18 April 2009 03:46:04 Henrique de Moraes Holschuh wrote:<br />> On Fri, 17 Apr 2009, Michael Biebl wrote:<br />> > Henrique de Moraes Holschuh wrote:<br />> > > On Fri, 17 Apr 2009, Michael Biebl wrote:<br />> > >> I think, one missing piece is a proper interface for updating init<br />> > >> script priorities (if the depencies or the list of runlevel changes) in<br />> > >> a policy compliant way.<br />> > > <br />> > > There is no such interface in this case (if we had one, insserv would have<br />> > > to make it a no-op). You have to edit the initscript metadata directly<br />> > > (because it is embedded in comment headers on the initscript itself) to do<br />> > > such changes, then tell the system to rebuild the initscript dependency<br />> > > tree.<br />> > <br />> > How do you do that exactly while preserving local modifications?<br />> <br />> The local modifications have to be done on the initscript headers, which are<br />> conffiles since the dawn of time. The user is warned that by switching to a<br />> dependency-based initscript system, the old order information is deemed<br />> irrelevant and thus completely ignored.<br />> <br />> There is also an override directory that can be used to change the<br />> dependency headers instead of editing the initscript, but we should get rid<br />> of any need to ship files in there as part of the release goal (local admin<br />> can place stuff there as he wishes).<br />> <br />> So, you can have local modifications to the *DEPENDENCY* information in an<br />> override directory.<br /><br />I'm pretty sure there is a misunderstanding here. An interface for modifying<br />unmodified script properties (such as what runlevels it starts/stops) is<br />desirable for use in package maintainer scripts when a new version of the<br />package wishes to change the scripts start/stop or sequence/dependency<br />properties. That is what Michael is poking us about.<br /><br />An interface for this was proposed for legacy (aka sysv-rc's) update-rc.d:<br />http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html<br /><br />The discussion went cold after Michael posited that the proposed interface is<br />prone to error because it relies on a human to write out a snippet of shell<br />code in a maintainer script. A similar interface could exist for insserv's<br />update-rc.d. I am without any better ideas at this time.<br /><br />> <br />> > Do you propose maintainer scripts should add special case code for insserv?<br />> <br />> I don't think that would be needed. During a dpkg run, a single insserv run<br />> at the end of the dpkg run should be scheduled (if insserv is active) via<br />> the dpkg triggers and also by any calls to update-rc.d (which will just<br />> schedule the insserv run, really), as well as changes to /etc/init.d/* and<br />> the insserv override directories.<br /><br />Actually, I do not believe it would be good to have insserv run on a<br />dpkg-trigger, that could potentially open the door for larger problems than<br />can occur when each script is inserted individually at package postinst time.<br />In the latter case, if an error occurs it is due to only one script<br />addition/modification and the problem is more easily rectified.<br /><br />> <br />> Nobody said anything about getting rid of non-dependency-based boot for<br />> Squeeze, BTW. We should aim to make dependency-based (and if at all<br />> possible, parallel execution) perfect, and the default... but not the only<br />> option, at least not yet. Maybe for squeeze+1 or squeeze+2.<br />> <br /><br />Thanks, Kel.</p></body></html>