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
