[Pkg-sysvinit-devel] Debian Buster release to partially drop non-systemd support

[Petter Reinholdtsen]

[Thorsten Glaser]
> Hmm. This does not answer the question, while it does point out one
> package. I’d rather sysvinit not depend on insserv, it used to work
> fine without that kind of added complexity, and AIUI, it was only
> used for parallel boots

Note, I can with authority, as the person introducing dependency based
boot and shutdown ordering in Debian, report that insserv were not
introduced for parallell boot, nor for boot speed.  It was introduced to
correct broken boot and shutdown ordering using a system wide reordering
of every scripts at once.  This was needed as it proved impossible to
get every package maintainer involved in a boot sequence reordering to
lift together in a finite amount of time, where the last one in a
sequence had to change its number, before the second to last changed its
number, and so on and so forth.  There were lots of incorrect sequence
numbers in the boot and shutdown sequence before we introduced
dependency based boot ordering, and this was solved when we introduced
dependency based boot ordering.

By all means, feel free to try to reintroduce the static sequence number
ordering again, if you believe it is a sensible way forward.  I
recommend to use the dependency information provided in the packages to
verify you get it right.  The /usr/share/insserv/check-initd-order
script can be used to compare the sequence numbers with the
dependencies, to detect any errors.

After we introduced dependency based ordering, the sequence number that
used to be passed to update-rc.d was made obsolete, and it is not really
used any more.  This means the number, if it is provided, can no longer
be trusted.  The 'start/stop' arguments for update-rc.d is no longer
supposed and have not been supported for several years.  There is no
going back to static sequence numbers without changing around 1000
packages to add these sequence numbers back.  I wish you luck motivating
the maintainers to reinsert them.  Personally I was a very happy when I
did not have to pick a number between 00 and 99, and instead could just
state relationships with other init scripts.

Just wanted to clear any misunderstanding about the use of insserv being
related to speed and running scripts in parallell.  It is not true.
Insserv provided correct ordering, and a byproduct was that correct
ordering made it possible to run scripts in parallell for higher speed
using startpar.

-- 
Happy hacking
Petter Reinholdtsen