Bug#727708: loose ends for init system decision
Michael Stapelberg <stapelberg@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: