Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
init systems"):
> The implication here appears to be troubling for any upstream who wants
> to rely on specific features of a given initsystem.
Yes, indeed.
> The implication of this proposed GR seems to be that those tools would
> be unfit for inclusion within debian unless someone erects all the
> additional scaffolding that runit provides (process supervision,
> pipelined logfiles with autorotation and log msgs just sent to stderr,
> restart on abnormal termination, no need for daemonization, clean
> process initialization, etc), but does so outside of runit.
But runit is exactly the scaffolding needed to do that, and already
exists! runit can coexist peacefully with sysvinit, systemd, upstart,
or whatever. There is no problem depending on runit because runit
doesn't demand being pid 1, so it is nonexclusive.
> This isn't surprising or specific to init systems, of course -- it's how
> free software works.
The problem with init systems is that you can have only one.
If people want to make Debian derivatives that work only with a
particular init system, that's completely fine. The reverse - trying
to put back support for sysvinit, if it gets taken out of Debian,
would be very very difficult. As the upstream for our ecosystem, we
in Debian have a special responsibility to retain the flexibility our
downstreams might want.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21569.13608.388043.939...@chiark.greenend.org.uk
