Michael Stapelberg <stapelb...@debian.org> writes: > That being said, I just checked and realized the package is not > available on non-linux. I’ll look into that now, since intuitively there > is no reason for this.
Thank you, Michael. That would indeed make things much easier. I think Ian is being excessively dramatic about very simple conditional integrations, but still, avoiding the conditional entirely is useful. One approach that would, I hope, minimize Ian's concerns is to provide a libsystemd-daemon-dev on non-Linux ports that just stubs out the calls, and that, on those architectures, provides some sort of dummy empty library that does nothing and adds no dependency. (There may be an elegant way to do this with a linker script.) That way, the exact same build process can be used everywhere, and everything just quietly disappears on non-Linux ports where systemd isn't available, without even adding a dependency on an (on that platform) useless shared library. What I used for lbcd is: #ifdef HAVE_SD_NOTIFY # include <systemd/sd-daemon.h> #else # define SD_LISTEN_FDS_START 3 # define sd_listen_fds(u) 0 # define sd_notify(u, s) 0 #endif which of course only stubs out the two major calls and doesn't address the rest of the API. That would need to be expanded to at least account for sd_notifyf (which will require a variadic macro, but that shouldn't be a problem in Debian) and sd_booted. I'm not sure what the best thing to do about the sd_is_* calls would be. One possible approach would be to just define them all to -ENOSYS, since they generally wouldn't be called when sd_listen_fds isn't available, although that would be a problem if any package ever used those APIs outside of a systemd context. (But I'm not sure why one would do that.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
