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

[Dmitry Bogatov]

[2019-04-22 19:07] Alessandro Vesely <vesely at tana.it>
> > On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote:
> > I agree, better not to break things if we don't need to, but introducing
> > complexity to support broken setup?
> I thought that script was way less complex than insserv...

Hm, seems I was prejudced. Sorry. Probably `insserv` really could be
simplified by replacing with high-level language implementation; but it
is not for me to decide.

Probably you want to propose such change to insserv's upstream.  He is
subscribed to this list, I believe, but you may wish to report it
separately.

History knows precendends: TexInfo >= 5.0 was succesfully reimplemented
in Perl instead of C.

> > 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'.
>
> Let me just note, in passing, that you're assuming any script belongs to
> some package.  What if a simple-minded user wants to write "Hello world"
> on every boot?

Normally,

	$ cat /etc/rc.local
	#!/bin/sh
	echo "Hello world"

but also you can modify any script in /etc/init.d/, so you will get your
"Hello world" text printed at any moment of boot process. Modifications
will be preserved between upgrades, and you will even have option to
merge your changes and Debian ones.

> Similarly, LSB defines installation of scripts, and casually mentions rc
> as an example implementation.  Given that the implementation can
> actually host more than the specification assumes, why artificially
> limit it?

Not artificially, just keeping scope of program in check.

> I'd never complicate things in order to support unspecified martians.
> The point is building every time from scratch, rigidly enjoining specs,
> like it or lump it, versus an incremental, tolerant, minimal changes
> operation.

What is the point of "incremental, tolerant, minimal changes operation"?

C compiler always builds .o file from source file always afresh, and it
reduces its complexity, and insserv(8) can be seen as compiler from
content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to
/etc/rc[0-6].d

The only possible reason to attempt reusing existing content of
/etc/rc[0-6].d is perfomance, and it does not apply.

I argue, that isserv(8) is compiler, not build tool like make(1), since
it is impossible to separate processing of any individual file from rest
of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together
are single input. It is possible to consider each /etc/rc[0-6].d as
separate output, but it is useless.
-- 
        Note, that I send and fetch email in batch, once every 24 hours.
                 If matter is urgent, try https://t.me/kaction
                                                                             --