Package: debian-policy Version: 4.6.2.0 Severity: important X-Debbugs-Cc: r...@debian.org
As part of reviewing #1039102, I took a detailed look at Policy 9.3 on system services and realized that it is largely obsolete and is not followed by most Debian packages that provide system services. Specifically: * There is no real documentation of systemd units except in the introduction, and most of the section describes init scripts as if they were the only way to start a service. * All packages are told they must use update-rc.d, but systemd units no longer use update-rc.d. They instead use deb-systemd-helper in ways that are not documented in Policy and I believe are maintained primarily in debhelper. * All packages are told they should use invoke-rc.d, but systemd units no longer use invoke-rc.d. They instead use deb-systemd-invoke, which also supports the policy-rc.d interface. * The policy-rc.d interface is undocumented. This part of Policy is also a bit of a mess of deleted sections due to a desire to avoid section renumbering. I started a rewrite of this section, but quickly ran into the question of how to document the correct invocations of deb-systemd-helper and deb-systemd-invoke. After thinking about this for a while, the conclusion I reached was that documenting this in Policy is both extra make-work that we do not have the resources to keep up with, and serves no real purpose for nearly every reader of Debian. debhelper is already maintaining the correct code to set up systemd services in close cooperation with the systemd and init-system-helpers maintainers, that code contains temporary workarounds and other fixes that Policy is not going to keep up with, and it's hard to justify duplicating that work in a Policy statement. I therefore would like to propose a first: I think Policy should simply say that any package that provides a system service should use debhelper and rely on dh_installsystemd to put the appropriate commands in its maintainer scripts. (We can then discuss whether we should do the same for init scripts and dh_installinit, although its stanzas are simpler.) Previously we have tried to avoid doing this, and have maintained the principle that debhelper is simply an *implementation* of Policy, and it still falls to Policy to describe what debhelper should do. However, I think it is now abundantly obvious that debhelper has considerably more development resources available to it than Policy has writers, debhelper developers are quite rightfully not waiting for things to be added to Policy before they can be implemented, and essentially every Debian package that does anything non-trivial uses debhelper now. I also don't see any truly useful purpose served by dumping a wad of shell code into Policy that essentially no one will use because it's what debhelper would add for them. I have some other questions about the rewrite of these sections (such as how hard we should try to retain section numbering), but I think we should resolve this question first, since it has dramatic effects on what text we should write. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-7 Versions of packages debian-policy suggests: pn doc-base <none> -- no debconf information
