Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
On Wed, 2019-12-04 at 18:04 +0100, Simon Richter wrote:
> On Wed, Dec 04, 2019 at 04:43:39PM +0100, Ansgar wrote:
> > For one of the problems (apt making unexpected decisions) that is
> > pretty close to what is the case. We do find such issues again and
> > again, including too late, i.e. only after a stable release, also for
> > other packages that aren't related to init systems.
>
> The experience is the same on the other side of the pond.
Well, as I said it's a problem with packages entire unrelated to init
systems as well (and the problems also don't involve init systems
there). The dependencies are just very complex and depending on the
set of installed packages apt might give very unexpected (and unwanted)
results.
To avoid unwanted switching between already installed init systems,
adding "Important: yes" to init systems (systemd-sysv, sysvinit-core)
has been suggested, but this would cause apt to be very unhappy about
intentionally switching to a different init system (similar to
uninstalling essential packages) and wasn't implemented for that
reason. Currently "init" has this flag to prevent unintentional
removing all supported init systems.
> I think the problem is the transition process that forces us to make
> dependencies weaker than they should be to have a satisfactory result.
Which transition? Intentionally switching init systems in an
installation?
> > In this discussion I provided a popcon graph which shows that systemd-
> > shim has significantly more installations than sysvinit-core; if you
> > prefer inline numbers: for stretch there are 3335 systemd-shim
> > installations and 775 sysvinit-core installations. So it looks like
> > something isn't quite as wanted. (And likely not all 775 sysvinit-core
> > installations even have systemd-shim, so the unwanted case is even a
> > bit larger; I'm too lazy to check that right now.) But even getting
> > some people to acknowledge this seems very hard.
>
> Could these be upstart based? IIRC installing systemd-sysv should deinstall
> systemd-shim, so the obvious broken configuration is locked out.
No, upstart has popcon 33 across all releases. Practically everyone has
systemd-sysv or sysvinit-core (99.5% in stretch; some users might not
have any init system installed and/or installed one outside the package
system; some popcon submissions are also just corrupted).
systemd-sysv doesn't have a conflict with systemd-shim in stretch. That
was only added in buster (after systemd-shim got incompatible with
systemd and was eventually removed). You can see the bend in systemd-
shim's popcon release after the buster release.
It also doesn't look like people transitioning from sysvinit-core to
systemd-sysv that kept -shim installed as systemd-shim popcon increases
after sysvinit-core already shrunk and stayed stagnant for a while (see
[1]).
[1]: https://qa.debian.org/popcon-graph.php?packages=systemd-shim+sysvinit-core&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1
> I'd be in favour of always including units along with init scripts, ideally
> as a strong requirement so we can disable the init script compatibility
> layer in systemd, and the same for cron files and timer units.
It would be nice to always have systemd service files for various
reasons. I don't think we can remove systemd's sysv-compat layer soon
(if we wanted to, probably bookwork would be earliest realistic
target).
For cron/.timer files one could extend crontab syntax to include some
marker that some things should not be run under systemd, same for
scripts in cron.daily. But it's always a bit of a hack... Anyway, a
bit far from the current topic.
Ansgar
Reply to: