On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote: > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > (At which point I'd suggest it's probably faster to convert it all to > > > meson or another new shiny, and saner, build system, but getting upstreams > > > to agree will be fun) > > > > CMake! :-) Meson outclasses CMake in functionality, clarity, and brevity. I doesn't make sense to consider switching to CMake at this point. > > This drags in libsystemd > > for sd_notify, and libsystemd is linked to way too much stuff including > > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > > we should just stop using sd_notify at all. It increases the attack surface > > of daemons a lot just to allow the service to be "Type=notify" rather than > > one of the other available approaches. Arch Linux is also systemd-based > > nowadays, but still does not link OpenSSH against libsystemd. > > > > This is related to philosophical differences between Arch and Fedora. > > That said, it probably makes sense for sd_notify to be its own library > instead of being part of libsystemd. I'm sure systemd upstream will > consider it now. :) I don't think a separate library would be particularly useful. sd_notify() as used by sshd just writes a static string to a unix socket. This can be implemented in ~10 lines of C, including error handling. If that is the _only_ thing needed from libsystemd, then open-coding it is a good option. I guess it'd make sense for systemd to provide a header file that provides a reference documentation as an inline function. One thing which is happening, mostly for unrelated reasons, it that systemd code is being changed to use dlopen() for various libraries which are usually not needed at runtime. The primary motivation for this is to omit such libraries from the initrd. But this also helps with overlinking. In systemd git main, libsystemd is only linked to libc, libcap, and libgcrypt + libgpg-error. A pull request to convert that that last pair to dlopen is under review. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
