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

Dmitry Bogatov KAction at debian.org
Thu Apr 18 11:24:25 BST 2019

[2019-04-17 18:02] Alessandro Vesely <vesely at tana.it>
> On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote:
> > 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.

As far as I know, "A depends B, B depends A" situation is called
RC-critical bug.

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

On my system no gaps: 01, 02, 03, 04, 05, 06 in rc2.d/

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

If you have special needs -- it is okay. If ordering is wrong -- report
bug. The whole idea of Debian is to ship things that work.

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

To be honest, I have rather basic knowledge, how things worked before
LSB. But as you describe it, manual moving symlinks feels like manual
editing output of `gcc'.
        Note, that I send and fetch email in batch, once every 24 hours.
                 If matter is urgent, try https://t.me/kaction

More information about the Debian-init-diversity mailing list