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

Michael Biebl biebl at debian.org
Mon Apr 20 16:11:24 UTC 2009


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.

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.
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.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20090420/4b432be6/attachment.pgp>


More information about the initscripts-ng-devel mailing list