Hi Ian,
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
>> thanks for your mail. This feature request was already raised upstream
>> and upstream decided to not implement it. Please see the provided URL
>> for more details.
>
> I'm afraid I find upstream's response there unconvincing. Do you
> think you might be able to persuade them ? What would your view be as
For this particular feature, that seems unlikely to me based on previous
discussions.
> the Debian maintainer, supposing I were to supply a patch to implement
> the feature - would you be willing to carry the patch ?
No. This feature request provides a new API to daemons, which would then
only be available on Debian. I think it’s a horrible idea to carry such
a patch.
>> I also fail to see in which way:
>> #include <signal.h>
>> raise(SIGSTOP);
>>
>> was any simpler than this:
>> #include <systemd/sd-daemon.h>
>> sd_notify("READY=1");
>>
>> And people can just use the .pc file to add libsystemd-daemon to their
>> build, so that's dead easy.
>
> This of course doesn't answer the question about the build- dependency
> (which as Enrico notes probably involves additional configure tests
> etc.) Speaking as the author of a daemon, it's really quite
> unattractive.
The text you quote speaks about a pkgconfig file. Are you familiar with
autotools and pkgconfig in particular? pkgconfig is an elegant mechanism
to declare a build dependency (which I also use when I’m not using
autotools). Adding a new build dependency to a project using autotools
with pkgconfig is _really_ simple. In case a project already declared at
least one pkgconfig dependency, it is literally a one-line change :-).
> You (Michael) half-suggest copying libsystemd-daemon's daemon.c into
> the package source tree, but of course this is (as you evidently
> recognise) not a very good idea. We should be recommending something
> good.
Agreed. I’d recommend to just not worry too much about the
dependency. Or if you do worry, drop in the file. Or copy the
function. With all the implications that approach has :-).
>> Another big problem with raise(SIGSTOP) is that if done on an init
>> system that can't handle it will result in a freeze. OTOH
>> sd_notify() handles this gracefully and just becomes a NOP.
>
> It seems to me that this would be handled by running the daemon with
> an argument so that it knows what to expect. By default it will
> probably call daemon(3), after all, and there'll have to be a way to
> tell it not do that. So I don't think this is a realistic problem.
Ugh, another argument, just for such a minor feature?
Sorry, I’m not at all convinced that your suggestion is more beautiful
than what we have right now :-).
--
Best regards,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
