On 2024-05-12 13:11, Nicolas Graves wrote: > On 2024-05-12 12:36, Eli Zaretskii wrote: > >>> From: Nicolas Graves >>> Cc: monnier@iro.umontreal.ca, ludo@gnu.org, emacs-devel@gnu.org, >>> andrew@trop.in, guix-devel@gnu.org, bjorn.bidar@thaodan.de, >>> rudi@constantly.at, felix.lechner@lease-up.com >>> Date: Sun, 12 May 2024 09:50:06 +0200 >>> >>> On 2024-05-12 09:29, Eli Zaretskii wrote: >>> >>> > Thanks. What was the motivation for this, again? >>> >>> A light summary (all is in the preceding exchanges in the mailing list): >>> >>> - Ludovic Courtès suggested this change because linking with systemd is >>> unnecessary (very light usage), and increases the attack surface. >>> >>> - Rudolf Schlatte highlights that Lennart Poettering says that the >>> notify protocol is stable and independent of libsystemd. >>> https://mastodon.social/@pid_eins/112202687764571433 >>> https://mastodon.social/@pid_eins/112202696589971319 >>> This mastondon thread itself contains a lot of info/answers about >>> this, including examples of similar work on other projects: >>> - https://github.com/FRRouting/frr/pull/8508 >>> - https://github.com/OISF/suricata/pull/10757 >>> Lennart Poettering also says that the protocol has been stable for a >>> decade and will surely be for at least another decade. >>> >>> This should also answer the worry about significant maintenance. >> >> I'm sorry, but I'm wary of believing such assertions, especially when >> systemd is involved. E.g., what's to prevent people from asking us to >> support the various forks of systemd as well? > > Don't they also support this precise protocol? > > Originally this thread was precisely about some limitations about > emacs's integration with GNU shepherd, exposing a "manual" pid-file > solution I found, and Ludovic answering "great, but look GNU shepherd > can emulate notify protocol's server side and GNU emacs can do it on the > client side". What I get from that is that systemd is so ubiquitously > used that even GNU Shepherd needed to emulate systemd's notify protocol > to properly manage some services, this protocol is probably already > emulated in most init system (is it?). In my own experience, it's indeed > simpler to rely on it rather than manually implementing proper > emacs-shepherd integration. > >> Reimplementing everything in-house doesn't scale, definitely not in a >> project as large as Emacs. So the argument about smaller attack >> surface doesn't really convince me. Emacs uses quite a lot of >> external libraries to the benefit of our users, and that will not >> change any time soon. > > Lennart himself wrote "if all you want is sd_notify() then don't bother > linking to libsystemd, since the protocol is stable and should be > considered the API", I'm (with my biases) more worried about "if all you > want" and what happens if users ask for deeper integration with systemd > than these two functions than about systemd's stability promise. > > One example is what I did with my pid-file emacs-shepherd integration : > be able to notify (in the sense of libnotify, not systemd) when server > has started but is not ready yet. This could be done with some smart use > of sd_notify_reloading, and would require the vendoring of this other > function (although this one is provided as such by Lennart too ; but any > deeper use (I can't find an example though) might be harder to > implement). I'm not sure any use outside this protocol is not far-fetched for emacs, can't find an example that would take advantage of libsystemd outside of the notify protocol and what's already there. Here another working patch taking into account your remarks Eli.