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

Ian Jackson ijackson at chiark.greenend.org.uk
Thu Apr 18 11:43:24 BST 2019

Dmitry Bogatov writes ("Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable"):
> [2019-04-17 18:02] Alessandro Vesely <vesely at tana.it>
> > 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.

If shipped by Debian but it can perhaps arise due to old packages,
ad-hoc packages, etc.  I agree that it's wrong but ISTM that it is
better not to break things if we don't need to.

But I think the current behaviour of insserv in this situation is to
bomb out completely and refuse to operate, isn't it ?  So it already
fails to disturb the existing symlinks ?

As for "stable sort":

So IMO if someone wants to send a patch which improves the algorithm
so that it preserves more of the existing link ordering, when
right now it doesn't care, we ought to consider it.  (We'd want to
be sure it didn't have any meaningfully different behaviour in
"normal" configurations.)

Note that the existing scheme parallelises things when the
dependencies permit, and we should not take a patch which fails to
parallelise things just because the existing links aren't parallel.


Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

More information about the Debian-init-diversity mailing list