On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote:
> 3. Start a discussion on debian-devel to see if we can come up with some
> idea for how to declare dependencies on availability of system
> services.
Do you mean "systemd features", or do you mean system services more
generally?
If the latter, we've had this class of bugs for years, particularly in
chroots, even before systemd existed: if a package relies on a system
service (perhaps most frequently the D-Bus system bus, but also things
like avahi-daemon, BlueZ, firewalld and nslcd), package dependencies
can ensure that the system service is *installed*, but cannot ensure
that it is *running*.
For example, I've seen this recently with packages adding build-time tests
that fail when run in a chroot (or a Docker container) that does not have
a D-Bus system bus running, because "Depends: dbus" isn't sufficient to
make that facility available in a chroot. Such tests need to either run
a mock system bus or be skipped gracefully when run by Debian buildds,
and if skipped at build-time they should preferably run as autopkgtests
instead. This is not unique to systemd: the same situation would exist
on pre-systemd Debian versions, or in Devuan (assuming Devuan builds in
a minimal chroot like Debian does).
I agree that having both systemd and sysvinit does make this situation
more problematic, because expectations for a bootable system with a
non-default init system like sysvinit are higher than expectations for
a chroot or Docker-style container with no init system at all.
autopkgtest documents the isolation-container restriction as implying
that services *can* be started, although it doesn't actually document
that restriction as implying that installed services *will* be
started. Amusingly, this means a Docker virtualization backend for
autopkgtest will probably be unable to advertise isolation-container,
because Docker containers usually don't run an init system like sysvinit
or systemd.
smcv
