Making it possible to uninstall initscripts / insserv and facilities

[Michael Biebl]

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.


Somehow, all the ideas I could come up with feel like hacks.
Personally, I would probably prefer b/, as the hack would be isolated to
one package.

But maybe I'm missing some aspect or another clever idea.

So I'd like your opinion on this matter.

Regards,
Michael




[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintainers@lists.alioth.debian.org;tag=initscripts-dep
[2]
https://docs.google.com/spreadsheets/d/1soRksM8sVs7R6hpOy8sfHmX9oavtcEm8KTHjt-kNfGM/edit?usp=sharing
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20151124/c3d78cba/attachment.sig>