Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely vesely at tana.it
Wed Apr 17 17:02:23 BST 2019

On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote:
> [2019-04-15 09:14] Alessandro Vesely <vesely at tana.it>
>> Nowadays, stable sort algorithms are really widespread.  Adjusting links
>> without subverting their existing order is not that hard.
> I am not going to implement it, but even as user I fail to understand
> your proposal.

To configure a stable boot sequence.

> Right now insserv implements little more than topological sort. You can
> modify relations between scripts by editing LSB headers. What do you
> mean 'adjusting links without subverting existing order'? Mind to provide
> example?

I just meant respecting the existing order, either if possible or if a fix is
not at all obvious.  Suppose A requires B and B requires A, a circular loop
which is somehow resolved by having S10A S20B.  Now, you want to insert links
for C, which is new.  If C requires B, you can insert it at S21C, even if C
doesn't require A.  That is, assume that the existing configuration works.

I recall having seen all links renumbered as 01, 02, 03, ...  On the machine
I'm writing from now --a client where the boot sequence was never tampered
with-- links are numbered with gaps.  I see several 01's, a single 02, then 14,
16, ...  Perhaps unconditional renumbering was changed since I posted that bug?

To edit LSB headers may make sense for one's own scripts.  Arbitrary insserv
overrides don't seem to be the right thing to do... Or is it customary?  Bottom
line, I've been trying to recover some of the flexibility we had before LSB's.
 I know that train has left many years ago...


More information about the Debian-init-diversity mailing list