Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:12 PM Russ Allbery <r...@debian.org> wrote:
> 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 > >
