[Pkg-sysvinit-devel] Bug#806438: Bug#806438: update-rc.d: Do not fail when initscripts is not installed

[Felipe Sateler]

On 27 November 2015 at 10:54, Petter Reinholdtsen <pere at hungry.com> wrote:
> [Felipe Sateler]
>> On systemd systems, however, the ordering sequence is not used, and all
>> that is required is that enable/disable links are present. So in systemd
>> systems we can force insserv to generate the links even if the ordering
>> is wrong.
>>
>> If a systemd-only system then installs initscripts, because initscripts
>> calls update-rc.d in postinst, that will recompute the sequences, so the
>> correct ordering should be reestablished afterwards.
>
> While this approach seem like a sensible one, there is one failure mode
> I would like to discuss first.
>
> The scenario go like this.  On a system with systemd and no initscripts
> package installed, several packages are installed and they work just
> fine with systemd.  Then the system owner decide to switch away from
> systemd to sysvinit and installs the initscripts package for this to
> work.
>
> But one or more of the already installed packages have a dependency bug
> in their init.d scripts.  One of their required-start or required-stop
> facilities are not available from any init.d scripts.  This will cause
> insserv to refuse to install the initscripts package because of this.
> The postinst fail when update-rc.d try to insert the new init.d scripts,
> because it is impossible to order the current set of installed init.d
> scripts.  It will become impossible to install new packages until the
> initscripts package is purged, and the only way to fix it is to
> installed fixed versions of all packages with broken init.d scripts (or
> edit the problematic init.d scripts).
>
> The way the update-rc.d script and insserv work today will ensure the
> boot sequence is always consistent, and any new package breaking the
> consistency will fail to install.  By adding -f to the insserv call,
> this will no longer be true, and an broken boot dependency graph will be
> allowed to exist, and only stop working when the -f is removed.

A broken /sysv/ boot dependency graph. The relevance of the qualifier
being that this is not a problem unless one is actually booting
sysvinit. Eg, a service might have both an init script and a systemd
unit, in which case systemd would completely ignore the initscript.

>
> Is there a good way to avoid this?  Perhaps we could look at teaching
> insserv how to handle multiple provides values, and list all the
> initscripts facilities in a dummy script?  Or perhaps add some '-i
> ignorefacility' option to insserv and ask it to ignore all initscripts
> facilities when initscripts isn't installed?

Do we want to break installs when an init script is broken but the
user is using systemd and not sysvinit? I think this is the question
we should be asking. The patch I proposed essentially answers "no".
That we check for mountkernfs.sh, which lives in package initscripts,
I consider only a proxy for the real question: is this system likely
to ever boot into sysvinit?

By following this reasoning, I think that failing to install other
services due to broken LSB headers is not the correct approach.

I'm afraid I don't see any other way than triggering error at the
point where we detect this might be a problem: when initscripts is to
be installed again.

-- 

Saludos,
Felipe Sateler