Daniel Kahn Gillmor:
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.
Ian Jackson:
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.
Daniel Kahn Gillmor:
nevertheless, runit behaves differently when it is pid 1 than when
> it is used in a subordinate role to another initsystem. If i'm
> upstream and i'm building mechanisms that integrate with runit *as it
> behaves as pid 1*, the implication seems to be that my work would not
> be welcome in debian.
Ian Jackson:
Are you saying that a daemon author would want to write code which
> only worked if runit was pid 1 ?
Daniel Kahn Gillmor:
Consider a tool that integrates in some way with /etc/runit/1 or
> /etc/runit/2 or /etc/runit/3, which are only relevant for systems
> with runit as pid 1 (see runit(8) for more details). Such a tool
> should not be RC-buggy just because it's useless on a system that
> uses systemd or sysvinit.
Perhaps if you picked something other than runit you'd make your point
more effectively. Try using the case of someone who makes a tool that
depends from System V init running as process #1. It is hardly
farfetched. I've seen at least two people publicly point out in the
past several months that they had something set up in /etc/inittab that
broke when they switched to an alternative bootstrap system. (A lot of
people conflate "init" with "rc". It's not System V init that other
bootstrap systems sometimes provide shims and compatibility mechanisms
for. It's System V rc, more specifically the /etc/rc?.d/* scripts that
it runs.) There's also a Debian bug or two. So the question that you
should be asking to make your point is probably this: The resolution
says that "In general, software may not require a specific init system
to be pid 1.". Does this mean that softwares that make use of
/etc/inittab, which is peculiar to (in Ian Jackson's own words) "a
specific init system" (its contents, outwith sometimes the run level
line, being not processed at all by any of upstart, systemd, runit-init,
s6-svscan, the nosh system or service managers, minit, jinit, or finit),
are unfit for inclusion in Debian according to Ian Jackson's resolution?
* https://lists.debian.org/debian-vote/2014/03/msg00103.html
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747742
Requiring that people be bootstrap system neutral has perhaps unintended
consequences, one of which is disappointing the spectators (in the press
and on other mailing lists) who mistakenly thought that M. Jackson was
championing the System V init status quo ante. Proper neutrality, it
turns out once one sits down and actually looks at it, makes work for
the maintainers of old softwares that only work with System V init,
too. M. Jackson, perhaps unintentionally, is pushing in the final nail
in the coffin of /etc/inittab . (-:
--
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/5441cff1.4020...@ntlworld.com
