Re: [draft] Draft text on Init Systems GR

[Ansgar <ansgar@43-1.org>]

Russ Allbery writes:
> Ansgar <ansgar@43-1.org> writes:
>> Note that this would also block updating upstream packages to new
>> releases, possibly delaying development for a long time.  I don't think
>> we need much slower development cycles.
>
> I'm not sure why you think this is the case.  Could you explain more about
> what upstream package blocking you expect?  Upstreams that only support
> systemd don't need to wait for a Policy specification of the facilities
> they rely on under Ian's proposal;

https://lists.debian.org/debian-vote/2019/11/msg00106.html was still
mentioning new logind features so I'm not sure that's out of scope.

So three hypothetical examples:

 - a hypothetical GNOME version that requires a build-time choice
   between `systemd --user` and the traditional session implementation;
   (GNOME can use `systemd --user` already[1], but it's not a build-time
   choice.)  I guess elogind could in theory start a `systemd --user`
   instance even when pid-1 is not systemd, but it's probably not
   realistic to expect that to be implemented.

   As far as I remember consolekit vs systemd-logind was a build-time
   choice in the past for some programs.

    [1]: https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

 - a hypothetical network management program that requires a build-time
   choice between using systemd-networkd or isc-dhcp-{server,client} to
   manage network connections.  (Had NM used networkd would likely have
   saved me some fiddling with settings recently and some things would
   just have worked out-of-the-box.)

In case of build-time choices someone could submit a patch to switch the
program to use another option even when this provides a less good
experience for people using systemd (though still usable).

What would happen then?  Would the maintainer have to apply the patch?

 - a hypothetical GNOME version requires (and does not really work
   without) a new or updated logind interface that elogind doesn't
   provide yet, but that could be implemented.  Say for some device
   access or so.

Would updating the software be blocked?

> the Policy discussion is only about
> general adoption of the facility to replace existing Debian-specific
> approaches.  Ian's proposal only requires that the maintainers accept
> patches to port systemd-only software to other init systems once those
> patches have been written, and asks that Policy not require systemd-only
> services be used by packages that aren't otherwise systemd-only without
> this specification and transition period.

I've less concerns about delaying replacing Debian-specific bits, say by
adopting tmpfiles.  That's slow anyway ;-)

(Though I would like to see Policy recommending packages to ship
tmpfiles stuff to create directories under /var and/or /etc in a safe
way; and to recreate them if an administrator deleted for example
directories under /var/cache.)

Ansgar