Bug#727708: loose ends for init system decision

[Michael Stapelberg <stapelberg@debian.org>]

Hi Ian,

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> > This is particularly the case for build-dependencies on an avowedly and
>> > intentionally non-portable program.  Of course this can be made
>> > conditional, but this is IMO too fiddly.
>> 
>> Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
>> goal is to enable optional upstream support for systemd, that will be
>> sufficient.  Besides, in general, it's up to the packager to decide what
>> is or is not too fiddly in how they want to package software.
>
> Adding [linux-any] to the Build-Depends is not sufficient.
>
> It is also necessary to make the actual source code conditionally use
> sd_notify, using #ifdefs or other similar techniques.  The conditional
> compilation will have to be automated (perhaps with autoconf if the
> package has it - an then we need new --with[out]-systemd configuration
> options to avoid miscompilation; or perhaps in an ad hoc way if the
> daemon doesn't use autoconf).  The fact that the systemd-specific
> command line option may or may not be compiled in needs to be
> mentioned in the documentation, along with text which allows the user
> to know whether it's included in the version they actually have.
>
> This turns what could be a simple change into a multi-part epic
> involving all of the components of the package: primary source code,
> upstream build system and portability layer, Debian build system,
> documentation, and so on.
No, this is all not true :).
libsystemd-daemon already contains the conditionals necessary to be a
noop on non-linux:
http://sources.debian.net/src/systemd/204-5/src/libsystemd-daemon/sd-daemon.c

Therefore, you can just use it, and don’t need to use any conditionals
on your end, neither in the compilation process, nor in the code itself.

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.

-- 
Best regards,
Michael