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