[Pkg-sysvinit-devel] Bug#668354: /etc/rcN.d/[SK]* symlinks are ignored if not mentioned on the /etc/init.d/.depend.* TARGETS

[Teodor MICU]

2012/9/19 Marcin Owsiany <porridge at debian.org>:
> AFAICT the issue is that:
>  - muse creates symlinks in /etc/rcN.d directly, rather than using
>    update-rc.d, thus insserv never learns about it,
>  - when insserv is installed and not explicitly disabled, the symlinks
>    are completely ignored

No, insserv does learn about them after the first execution (insserv
command or any update-rc.d) because the init script has LSB headers.

> I think this title summarizes the issue much better.

A more correct title would be "/etc/rcN.d/[SK]* symlinks are ignored
if not mentioned on the /etc/init.d/.depend.* TARGETS".

> Now, whether this is actually an RC bug is unclear to me. The Debian
> policy mandates that init scripts are installed using update-rc.d.
> One might say that if muse does not follow Debian policy, it does not
> seem fair to claim that sysvinit has a bug...

The bug is that the boot process should not depend on the insserv
internals (/etc/init.d/.depend.*). You have a S/K??service link than
execute it accordingly.

> If sysvinit cared about compatibility with products such as muse, it
> could use the following approach:
>  - scan all symlinks for runlevel N
>  - strip the [SK]XX prefix
>  - filter away the names which are in /etc/init.d/.depend.* $TARGETS
>  - if any names remain, they must be such legacy scripts - run them
> However this procedure would not preserve the correct ordering of
> scripts..

I think you are talking here about the re-ordering of symlinks on
insserv or update-rc.d executions. Maybe I wasn't clear, but I was not
arguing about this ordering which is fine as it is now.

Cheers