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

[Dmitry Bogatov]

[2019-04-18 18:30] Alessandro Vesely <vesely at tana.it>
> On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote:
> > Dmitry Bogatov writes:
> >> 
> >> 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 ?
>
> At least, that's what happens at mine.  I had to write a quick script to
> overcome that, http://www.tana.it/sw/fix-init/.

I agree, better not to break things if we don't need to, but introducing
complexity to support broken setup?

Cycled dependencies or otherwise incoherent dependencies is broken
setup.  Fix it. We already discussed how to fix it. Asking to support it
is like asking to support  situation, when dependency of your package is
removed by `dpkg -r'.

> > 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.)
>
> Rather than a patch, I'd consider an alternative executable.  The link above
> displays a man page for the script.  I'm not advocating that script, as it has
> many defects.  However, I like its man page and its options.  I don't think

You can try introducing new package into debian:
insserv-with-support-of-inconsistent-scripts and make it Provides:
insserv.

> > 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.
>
> Here's a point I had never considered.  Perhaps, that's because I tend to boot
> very sparingly --even on laptops, since suspend works well enough.  I accept
> parallelism can be a very important point for several people.  An instance of
> diversity?

Data point: I do not care much of speed of boot (as long it is not 90s),
and I do not care at all of support for inconsistent LSB dependencies.

PS. About services starting before you can see config. There is
/sbin/rc.policy mechanism.
-- 
        Note, that I send and fetch email in batch, once every 24 hours.
                 If matter is urgent, try https://t.me/kaction
                                                                             --