[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#753589: systemd: missing pre-dependencies for runlevel(8) etc.



Policy says new Pre-Depends should be discussed on debian-devel so let's
try that. (Please do not derail this thread into discussing whether
systemd is a good thing or not, everyone is tired of that.)

Quick summary of #753589 for debian-devel readers: Essential:yes packages are
expected to provide their functionality while merely unpacked, even when
not yet configured. The new init package is Essential:yes, and the
functionality it represents includes sysvinit-compatible implementations
of runlevel(8), shutdown(8), halt(8), telinit(8), poweroff(8) and reboot(8).
At least runlevel(8) is actively used via invoke-rc.d in maintainer scripts,
leading to #753589.

(Side point: I'm also going to open a bug asking that invoke-rc.d stop
trying to determine the runlevel under systemd, because it's rather
meaningless. The same is probably true of Upstart.)

init pre-depends on a sysv-compatible init implementation to provide
those tools: sysvinit-core | systemd-sysv | upstart. This makes those tools
"transitively Essential", so they are also expected to function when
merely unpacked.

Under systemd-sysv, all of those tools are symlinks to /bin/systemctl.

Michael's proposed patch is simple:

> diff --git a/debian/rules b/debian/rules
...
> +# the SysV compat tools (which are symlinks to systemctl) are quasi-essential
> +# so we add the depencencies of systemctl to Pre-Depends
> +# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753589
> +override_dh_shlibdeps:
> +	dh_shlibdeps -psystemd -- -dPre-Depends -edebian/systemd/bin/systemctl -dDepends
> +	dh_shlibdeps --remaining-packages

resulting in:

> Control files: lines which differ (wdiff format)
> ------------------------------------------------
> Depends: libacl1 (>= 2.2.51-8), libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.17.2), [-libc6 (>= 2.17),-] libcap2 (>= 2.10), libcryptsetup4 (>= 2:1.4.3), libdbus-1-3 (>= 1.1.1), [-libgcrypt11 (>= 1.5.1),-] libkmod2 (>= 5~), [-liblzma5 (>= 5.1.1alpha+20120614),-] libpam0g (>= 0.99.7.1), libselinux1 (>= 2.1.9), [-libsystemd-daemon0 (= 208-5),-] libsystemd-journal0 (= 208-5), libudev1 (>= 189), libwrap0 (>= 7.6-4~), libsystemd-login0 (= 208-5), util-linux (>= 2.19.1-2), initscripts (>= 2.88dsf-17), sysv-rc, udev, acl, adduser, libcap2-bin
> {+Pre-Depends: libc6 (>= 2.17), libdbus-1-3 (>= 1.0.2), libgcrypt11 (>= 1.5.1), liblzma5 (>= 5.1.1alpha+20120614), libselinux1 (>= 2.0.65), libsystemd-daemon0 (= 208-5)+}

Expanded dependency tree:

libc6 is already quasi-Essential, via e.g. coreutils
libdbus-1-3 Depends: libc6 (>= 2.17)
libgcrypt11 Depends: libc6 (>= 2.15)
libgcrypt11 Depends: libgpg-error0 (>= 1.10), already satisfied in stable
libgpg-error0 Depends: libc6 (>= 2.14)
liblzma5 Depends: libc6 (>= 2.4), already satisfied in stable
libselinux1 is already quasi-Essential, via coreutils
libsystemd-daemon0 Depends: libc6 (>= 2.8), already satisfied in stable

Michael wrote:
> The Pre-Depends list is still a bit long.
> But I guess there is no way around to it.

I don't think that list looks too bad: all the libraries added to it
are quite self-contained. The only way I can see to reduce that list
would be to reimplement the sysv compatibility tools as one or more
separate binaries, in which case the question would be: how much
of their functionality is Essential? I don't see any reason why
it would be reasonable for a maintainer script to do anything
with those tools except runlevel, telinit q, or telinit u.

     S


Reply to: