On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
> Russ Allbery writes:
> > Until such time as we make a project-wide
> > decision to drop support for sysvinit, providing an init script for
> > straightforward daemons is part of packaging a daemon. If people are
> > unwilling to do this work, I don't believe we should accept the package in
> > Debian. In other words, I personally believe not providing an init script
> > should be an RC bug (as Policy currently indicates) given the current
> > project stance on init systems, except for the standard exception case of
> > packages that are specifically designed to only be meaningful with systemd
> > for which making them work with any other init system would require
> > significant porting (not just writing a simple equivalent init
> > script).
> That exception does not exist in Policy; there is only an exception for
> packages provided by the init implementation itself. Policy currently
> requires the "Loose coupling of init systems" option of
> https://www.debian.org/vote/2014/vote_003 as far as I can tell as
> services must be able to run under sysvinit.
> We already have several packages only shipping systemd units, including
> with socket activation (I did not check if any services cannot be
> configured to not listen on their own, but I wouldn't be surprised).
> Those with socket activation include: chasquid, cockpit-ws, erlang-base,
> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.
I actually don't agree with this policy proposal - I think that if we are
going to support non-systemd init at all in Debian, it needs to be more than
lip service, and that means policy needs to spell out that maintainers have
a responsibility to help hold the line - but there's one package in your
list above that I have specific knowledge of. The snapd package uses socket
activation, yes, but this is an optimization and the package could equally
be started using /lib/systemd/system/snapd.service.
However, the package does not ship an init script. There would be no point.
The snapd service as implemented upstream generates and manages systemd
units, including both .service and .mount units. Making snapd work with
non-systemd init would be a non-negligible upstream porting effort.
Snapd is also not straightforwardly portable to non-Linux kernels, which
IMHO is the principle reason that Debian should continue to care about
non-systemd init at all.
Should Debian refuse to allow a package into a stable release ("RC-buggy")
whose upstream has made technology decisions that tie it to a particular
sysvinit-incompatible init system?
Again, I think the current policy language is broadly correct and don't
think it should be dropped outright. I think now that we have more
experience with systemd as default, and more examples we can point to in the
archive, it is time to think about how we should add more nuance to the
policy.
> I wouldn't be surprised to see more services require systemd's socket
> activation in the future.
> (Also, see DBus-activated services, inetd-style socket activation,
> .timer units with their associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)
In my mind, the intent of the current policy language is to require an init
script matching any .service units, not for .socket or .timer units.
Perhaps the text should be refined to be systemd-specific instead of
continuing to treat "alternate init systems" generically, and then call this
out?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature