Hi all, This is a tentative proposal for next steps from a Policy standpoint given the result of <https://www.debian.org/vote/2019/vote_002>. I thought it might be helpful to lay out a possible way to sequence the work.
1. Downgrade the requirement to include an init script in a package with a systemd unit to "encouraged." This is the direct outcome of the GR, so I think we should make this change before the next normative upload, since there's no point in Policy being inconsistent with the GR result. I think there's some discussion to be had here about whether the correct level is "encouraged" or "optional." I'd also like to revise and merge my change that adds "encouraged" first, although if we decide "optional" is correct, that sequencing is, well, optional. 2. Do nothing further before January 6th. It's still the holidays, and subsequent steps are going to require some discussion, and I think it's worth taking a breath. 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. My thought process here is that while the GR permits packages to start using systemd facilities directly, doing that without somehow declaring that requirement in package metadata seems likely to cause bugs and upgrade issues, so we should try to provide some better facilities. I think there's an obvious gap here where we need a mechanism to declare a dependency on a system facility (as distinct from a package that may be installed but not running) such as tmpfiles.d, sysusers.d, the ability to rely on DynamicUser without creating a user for that purpose in maintainer scripts, systemd D-Bus facilities, socket activation, or so forth. This would be a way to provide better UI when someone on a sysvinit system tries to install a package that requires a systemd facility (via an upgrade scenario, for example). It also exposes in the archive what facilities are blocking use of packages on non-systemd systems, and thus provides a prioritized list of work for anyone who is pursuing exploration per paragraph two of the GR. This obviously is going to require some hashing out, and may well require support from the dpkg, apt, and aptitude teams. 4. Parallel to point 3, start fleshing out Policy recommendations for best practices for systemd units. Some initial candidates for security hardening: - DynamicUser (*without* removing useradd, see below) - ProtectSystem - ProtectHome - PrivateTmp - PrivateDevices - SystemCallFilter We probably also want to recommend Type=notify where possible and Type=exec where not, over Type=forking, when the daemon supports that. OOMScoreAdjust may also be worth setting some policy around. We should, of course, have an open discussion of other things that people would like to see documented as best practices. These are chosen because they only affect the unit file and don't add any additional assumptions on the availability of other services. 5. As the outcome of point 3 concludes, start documenting use of other desirable services that would allow simplification of Debian packages and allow package maintainers to use those services rather than the ones that Policy currently requires. My personal priority list looks like (roughly in order): - DynamicUser without useradd of a system user - tmpfiles.d - sysusers.d - Timer units - Socket activation but we should have an open discussion of what other facilities people think Debian would benefit from. I think we should prioritize the cases where it would be relatively straightforward for other init systems to provide the same functionality; for example, tmpfiles.d and sysusers.d can be supported by simply arranging to run the relevant systemd binaries at appropriate times. DynamicUser is a bit harder, but I think the minimum functionality to let the package keep working could be added to start-stop-daemon or some wrapper that it execs. As time goes on, we'll get a better feel for how much work folks will be doing going forward on supporting other init systems, and thus on how quickly we should move versus giving them time to determine how they want to support equivalent functionality. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>