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

Re: Integration with systemd



[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


Reply to: