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

[Alessandro Vesely]

On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote:
> [2019-04-18 18:30] Alessandro Vesely <vesely at tana.it>
>> On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote:
>>>
>>> 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?


I thought that script was way less complex than insserv...


> 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?

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?.


>> 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.


I append that to my to do list.


> Data point: I do not care much of speed of boot (as long it is not 90s),


(loading ClamAV database may take longer...)


> and I do not care at all of support for inconsistent LSB dependencies.


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.


> PS. About services starting before you can see config. There is
> /sbin/rc.policy mechanism.


Thanks for the tip.


Best
Ale
--