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

@@ -251,9 +251,9 @@ Depends:
  ${shlibs:Depends},
  adduser,
  gettext-base,
- lsb-base,
  libvirt-clients (= ${binary:Version}),
  libvirt-daemon (= ${binary:Version}),
+ libvirt-daemon-system-systemd | libvirt-daemon-system-sysv,
  iptables (>= 1.8.1-1) [linux-any] | firewalld,
  logrotate,
  policykit-1,
@@ -284,6 +284,50 @@ Description: Libvirt daemon configuration files
  This package contains the configuration files to run the libvirt daemon as a
  system service.
 
+Package: libvirt-daemon-system-systemd
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+ systemd-container,
+ systemd-sysv,
+Section: admin
+Conflicts: libvirt-daemon-system-sysv
+Description: Libvirt daemon configuration files (systemd)
+ Libvirt is a C toolkit to interact with the virtualization capabilities
+ of recent versions of Linux (and other OSes). The library aims at providing
+ a long term stable C API for different virtualization mechanisms. It currently
+ supports QEMU, KVM, XEN, OpenVZ, LXC, and VirtualBox.
+ .
+ This package contains the dependencies to make libvirt work with systemd.
+ (this is the default). This package is useless without the
+ libvirt-daemon-system package installed.
+
+Package: libvirt-daemon-system-sysv
+Architecture: any
+Section: admin
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+ lsb-base,
+Breaks:
+ libvirt-daemon-system (<< 5.6.0-4~),
+Replaces:
+  libvirt-daemon-system (<< 5.6.0-4~),
+Description: Libvirt daemon configuration files (sysv)
+ Libvirt is a C toolkit to interact with the virtualization capabilities
+ of recent versions of Linux (and other OSes). The library aims at providing
+ a long term stable C API for different virtualization mechanisms. It currently
+ supports QEMU, KVM, XEN, OpenVZ, LXC, and VirtualBox.
+ .
+ This package contains dependencies and init scripts to make libvirt work with
+ sysv based init systems. Using libvirt-daemon-systemd is preferred since the
+ init scripts are incomplete.
+ .
+ This package is useless without the libvirt-daemon-system package installed.
+
 Package: libvirt0
 Architecture: any
 Multi-Arch: same

debian/libvirt-daemon-system.maintscript

 rm_conffile /etc/logrotate.d/libvirtd.uml 5.0.0-2~
+# drop sysV scripts to avoid upgrade issues with virtlogd-admin.socket (LP: #1786179)
+rm_conffile /etc/init.d/virtlogd 5.6.0-3~ libvirt-daemon-system
+rm_conffile /etc/init.d/libvirtd 5.6.0-3~ libvirt-daemon-system
+rm_conffile /etc/init.d/libvirt-guests 5.6.0-3~ libvirt-daemon-system

debian/rules

@@ -180,9 +180,9 @@ override_dh_install-arch:
 
 	# Copy upstream files to debian/ so dh_* can find them
 	cp debian/tmp/usr/lib/libvirt/libvirt-guests.sh \
-	    debian/libvirt-daemon-system.libvirt-guests.init
+	    debian/libvirt-daemon-system-sysv.libvirt-guests.init
 	cp tools/libvirt-guests.sysconf \
-	    debian/libvirt-daemon-system.libvirt-guests.default
+	    debian/libvirt-daemon-system-sysv.libvirt-guests.default
 	cp src/logging/virtlogd.sysconf \
 	    debian/libvirt-daemon-system.virtlogd.default
 	cp src/locking/virtlockd.sysconf \
@@ -228,11 +228,10 @@ endif
 	# executable-not-elf-or-script
 	chmod 644 debian/libvirt-daemon/usr/share/bash-completion/completions/vsh
 
-
 override_dh_installinit:
-	dh_installinit -p libvirt-daemon-system --name=virtlogd --no-stop-on-upgrade
-	dh_installinit -p libvirt-daemon-system --name=libvirtd --restart-after-upgrade -- defaults 28 72
-	dh_installinit -p libvirt-daemon-system --name=libvirt-guests --no-stop-on-upgrade -- defaults 29 71
+	dh_installinit -p libvirt-daemon-system-sysv --name=virtlogd --no-stop-on-upgrade
+	dh_installinit -p libvirt-daemon-system-sysv --name=libvirtd --restart-after-upgrade -- defaults 28 72
+	dh_installinit -p libvirt-daemon-system-sysv --name=libvirt-guests --no-stop-on-upgrade -- defaults 29 71
 
 override_dh_installsystemd:
 	dh_installsystemd -p libvirt-daemon-system --restart-after-upgrade libvirtd.service

[Michael Biebl]

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.

[Guido Günther]

@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?

[Michael Biebl]

Hm, ok. I apparently missed that bit indeed. Sorry for the noise. This is way less problematic then. Still feels weird to have an empty -systemd package. I guess having a systemd-container | libvirt-daemon-system-sysv dependency would have worked just as well.

[Michael Biebl]

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.

[Andrea Bolognani]

all the systemd state stays with libvirt-daemon-system for the moment and we only moved the dependencies there

At 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 :)

[Michael Biebl]

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

[Andrea Bolognani]

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! :)