[Please CC me on replies.] Simon Richter wrote: > On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > If we're going to have a GR, part of the goal should be to either > > confirm the current state that we're never moving very far past the > > capabilities of sysvinit even when most people don't run it, or that > > we're allowed to use the full capabilities of our default init system > > even when there's no equivalent elsewhere. > > I doubt we have that choice. Those packages embracing systemd will > require all the features, and it will be hard enough to put our foot > down and insist that they restrict themselves to the set in the stable > release.
(Leaving the gratuitously adversarial assumption of inevitable problems aside...) By "the stable release", do you mean "the stable release of systemd" or "the stable release of Debian"? For the former, I certainly don't think it's reasonable to package software that depends on an unreleased or unpackaged version of systemd, and I doubt much software does so. For the latter, 1) that doesn't seem like a very reasonable limitation, 2) systemd supports upgrading itself without a reboot, and 3) even if we needed that for some reason, the ability to use the features present in stable is still far better than not being able to use any of the features at all. > If we want to fully adopt systemd, we need a faster policy process As Sam's original mail suggested, part of the problem is that policy folks don't feel empowered to create any policy around usage of systemd features, because the *official* stance is still "your package must work with sysvinit". Let's fix that, and *then* we can worry about whether we have a problem with policy keeping up. I have confidence in the Debian Policy Editors and their ability to handle various use cases and requirements. Also, not every aspect of the way two packages interact is or needs to be covered by Policy. Some aspects do (we should absolutely have policy regarding any use of presets, or how we generally want to handle users distro-wide, or when a periodic timer is appropriate or inappropriate), while other aspects don't (usage of transient units to run jobs, usage of systemd-tmpfiles, usage of timer units assuming a periodic timer is appropriate). > Priority: extra https://lintian.debian.org/tags/priority-extra-is-replaced-by-priority-optional.html