Hi, Björn Bidar <bjorn.bi...@thaodan.de> skribis:
> Stefan Monnier <monn...@iro.umontreal.ca> writes: > >>> Maybe some feedback on the Emacs side about this? There are indeed very >>> few places where systemd sd_* functions are called in emacs.c, should we >>> try and re-implement them instead of using the library as is? Would that >>> be a contribution Emacs devs would be interested in? That would >>> definitely be beneficial for Emacs on Guix as highlighted by Ludo'. >> >> It's hard to tell without seeing the actual patch. >> >> But if the code is sufficiently simple, it implements a protocol that's >> well documented, and it allows us to eliminate the dependency on the >> systemd library, we might like it. > > Would that make sense on systems where systemd is used? If libsystem is > already installed it would be more convenient for the user to use the > already installed and very likely loaded libsystemd instead of > reimplementing the feature. As I wrote, in the wake of the xz backdoor, many came to the conclusion that linking against libsystemd “just” to check a couple of environment variables (for socket activation) is hard to justify (libsystemd provides much more functionality than this bit.) > Ideally the support for other initrd system could implement a function > that is then called instead of the systemd codepath be it something > different or to reimplenent sd-notify. Maybe shepherd as something like > sd-notify of it's own? Shepherd does not implement the sd-notify protocol, but it implements socket activation, which is what Emacs currently uses AFAICS. HTH, Ludo’.
