Hi Andrew,

thank you for your kind words.

On Sat 19/Jul/2025 10:33:10 +0200 Andrew Bower wrote:
> On Fri, Jul 18, 2025 at 02:28:26PM +0200, Alessandro Vesely via Dng wrote:
>> On Thu 17/Jul/2025 18:59:04 +0200 Andrew Bower wrote:
> [...]
>>> I don't know what a new user gains from hacking or renaming init scripts
>>> rather than using tools to manipulate the symlinks.
>>
>> Another approach is to use /etc/insserv/overrides/. One can change required
>> libraries and runlevels there.
>>
>> My take is to use a fix-init script[*] that rebuilds the LSB header links
>> taking into account the existing situation, and also a concise config file
>> where I can override which scripts are run at which runlevel, with comments.
>> I prefer this because update-rc.d doesn't keep track of its invocations and
>> their purposes.
>
> Thanks for sharing your fix-init tool! I like the dry-run mode in
> particular - it gives (with -r 0) a clear picture of current differences
> from default.


yup fix-init -n -, to output on stdout.


> Do you think insserv doesn't do the dependency resolution correctly?
> Even with no renumbering requested, your script identified 3 initscripts
> to renumber on this host.


The idea was to try to respect anomalous overrides set out directly, rather
than insserv being akin to a compiler, where the links have the role of object
code; that is, you cannot operate directly on them. Probably a wrong approach.


> I can see that the insserv .start and .stop file extensions try to do
> something like your nice concise config file but with less expressivity.
>
> I see the insserv overrides and the config file as potentially a way for
> estate administrators to customise a set of hosts while symlink
> manipulation would allow the current setting to be changed for an
> individual host. But that's just one way of looking at it!
>
> FYI I have taken over maintaining sysv-rc-conf with the first release in
> 20 years: it has key limitations as to suitable use cases but I have
> dealt with a number of bugs and am now working on fixing the
> startup/shutdown use cases and other things. Sadly none of the fixes or
> improvements are in time for Excalibur.


I'll take a look at that package.


Best
Ale
--