Introduce libvirt-daemon-system-{systemd,sysv}
Move init scripts to separate package that allows people to experiment with alternative init systems while avoiding the problems that mixed init scripts and systemd units have in the current packaging. Thanks: Christian Ehrhardt for all the input Closes: #887911, #905772
- debian/control 45 additions, 1 deletiondebian/control
- debian/libvirt-daemon-system-sysv.libvirtd.init 0 additions, 0 deletionsdebian/libvirt-daemon-system-sysv.libvirtd.init
- debian/libvirt-daemon-system-sysv.virtlogd.init 0 additions, 0 deletionsdebian/libvirt-daemon-system-sysv.virtlogd.init
- debian/libvirt-daemon-system.maintscript 4 additions, 0 deletionsdebian/libvirt-daemon-system.maintscript
- debian/rules 5 additions, 6 deletionsdebian/rules
-
Hm, I'm not sure if this was a good idea. E.g. I don't see the init-system-helper state transferred from libvirt-daemon-system to libvirt-daemon-system-systemd (the state files in /var/lib/systemd/deb-systemd-*). This is non-trivial and there is no support for such a use case. I guess the best you could do is purge the state prior to the upgrade and throw away any admin changes. That's not nice though.
I think it should have been possible to solve #905772 by using dh_installsystemd and compat level 12. But maybe I'm missing some detail.
-
@biebl that's why all the systemd state stays with
libvirt-daemon-system
for the moment and we only moved the dependencies there - do you consider that still problematic? -
Be prepared that to get bug reports on upgrades which switches the init system for sysvinit users. I suspect apt will prefer installing
libvirt-daemon-system-systemd
on upgrades, thus removing sysvinit-core.Edited by Michael Biebl -
all the systemd state stays with
libvirt-daemon-system
for the moment and we only moved the dependencies thereAt some point we will still want to move all systemd-related files to the corresponding package though, right? So if that's not something that we can achieve we might want to rethink our strategy... I agree than it's weird and confusing to have an empty package.
Be prepared that to get bug reports on upgrades which switches the init system for sysvinit users. I suspect apt will prefer installing libvirt-daemon-system-systemd on upgrades, thus removing sysvinit-core.
Wouldn't apt favor solutions that don't involve removing packages?
Either way this definitely needs actual testing, especially in the kind of non-default scenario you mention - which is part of the reason we're doing the work in experimental :)
-
Wouldn't apt favor solutions that don't involve removing packages?
Not in my experience. See e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926316
-
Wouldn't apt favor solutions that don't involve removing packages?
Not in my experience. See e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926316
IIUC the situation would be a bit different in our case: for #926316, switching init systems was the only way for apt to satisfy the Recommends - not exactly what I would have expected it to prioritize, but I can at least see why that would make sense; in our case, however, dependencies would be completely satisfied either installing or removing a package, so I would expect apt to choose the former.
But of course we need to actually test the upgrade process to figure out what happens in reality! :)
Edited by Andrea Bolognani -
mentioned in merge request !169 (closed)
-
mentioned in merge request !163 (merged)