On 27 November 2015 at 10:54, Petter Reinholdtsen <p...@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
