Re: Review of proposals
Hi,
On Fri, Nov 29, 2019 at 09:07:58AM -0800, Russ Allbery wrote:
> Sam, I think you misunderstood Simon's concern. He's not looking for
> guidance for packages that don't work properly with sysvinit. He's
> looking for guidance for packages that don't work properly with *systemd*
> (the inverse of that problem).
No, Sam's interpretation was correct. My assumption was that in the other
direction it was already obvious that "it should work with systemd" was not
negotiable and no one was really asking for that. I'm not sure we need to
spell that out.
FWIW, I have exactly one program that might run into trouble with systemd,
as it has an in-place upgrade mechanism that will fork() and execve() in
the parent process to have the new binary provide service to new clients
while the existing sessions remain running, but I'm fairly sure that once I
package this, I can find a solution for that as well.
Sam's mail has soothed my main fear that this would create a regulation
vacuum precisely where I'd expect conflict -- packages that can optionally
use a systemd facility like systemd-tmpfiles but have fallback code for
non-systemd setups where that facility is not available. These seem to be
reasonably well defined.
I'm still unsure what that means for packages where systemd support is a
compile time option, and different code gets included depending on the
value of the --with-systemd option. I haven't had time to look at libvirt
in detail, but they have explicit systemd support, integrate into it and
have a strong dependency on systemd-sysv in bullseye, and upstream still
support FreeBSD as a host where no systemd support is available, so that
would be the most likely candidate, and also one that a lot of people
actually care about.
Simon
Reply to: