Making it possible to uninstall initscripts / insserv and facilities

[Felipe Sateler]

On 24 November 2015 at 14:54, Michael Biebl <biebl at debian.org> wrote:
> Hi everyone,
>
> a few days ago, I filed bug reports against packages which declare an
> explicit dependency on the initscripts package [1] and asked them to
> remove it.
> My assumption back then was, that this dependency was mainly added for
> the /run-transition and could be dropped now easily.
>
> Unfortunately, it turns out that it's not quite that simple.
> Some SysV init scripts declare hard dependencies (Required-Start,
> Required-Stop) on facilities provided by the initscripts package.
>
> insserv, which is used internally by update-rc.d, bails out, if such a
> dependency can not be fulfilled.
>
> Under [2], I started collecting some data.
> - Sheet 1 lists all the facilities provided by initscripts and how many
> init scripts use those.
> - Sheet 2 lists all occurences of such Required-(Start,Stop) dependencies
> - Sheet 3 is a sorted list of packages, which declare such a dependency.
> In the second column are the bugs I already filed. This means, we
> currently have ~30 packages which use the facilities from initscripts
> without an explicit dependency.
>
>
> Now, for possible ideas how to address this
>
> a/ Pere suggested to turn the Required- dependencies into Should-
> dependencies. This means, as long as initscripts is not installed,
> insserv does not fail, but potentially calculates a wrong ordering.
> This is not fatal for systemd though, as the ordering is not used by
> systemd, only the enabled state is relevant.
> sysvinit-core depends on initscripts, so we only would need to ensure
> that initscripts.postinst runs insserv to fix up a potentially incorrect
> ordering.
>
> Somehow this feels wrong though. If sysvinit is active, we really want
> those dependencies to be strict.
> The other downside is, that we have to touch 39 packages.
>
> b/ We patch insserv to simply make the facilities provided by
> initscripts a nop iff systemd is active, i.e. add a whitelist for
> facilities which may not exist.
>
> This would only require touching one package, but Pere didn't
> particularly like it. It certainly would be a hack.
>
> c/ We patch update-rc.d to not run insserv.
>
> Problem with this approach is, that we actually need the enabled
> symlinks for sysv-only packages. This is a K.O. criteria imho.
> We also tried so far to keep the enabled state in sync between sysv init
> scripts and native units.
>
> d/ We patch insserv to only create enabled symlinks but do not care for
> dependencies/orderings iff systemd is active. Installing
> sysvinit-core/initscripts would retrigger a insserv run which fixes up
> the ordering.

e/ Patch insserv to look for a flag file/setting somewhere in
/etc/insserv{,.conf.d}, which causes it to treat Required-* as Should*
(ie, conffile-version of --force). Then initscripts could ship such a
configuration, thus demoting dependencies only when initscripts is not
installed.

f/ Patch update-rc.d to use --force when initscripts is not installed.

These two options have the added advantage of not relying on the
active init, and thus could work while switching to sysvinit in the
next boot.
I think that, because update-rc.d is already debian-specific, encoding
package information there is not such a terrible thing to do.

-- 

Saludos,
Felipe Sateler