Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Russ Allbery <rra@debian.org>]

Roger Lynn <Roger@rilynn.me.uk> writes:
> On 15/01/2024 18:00, Russ Allbery wrote:

>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install the shared library and daemon even though it's an
>>    optional feature, because the shared library is a link dependency for
>>    the application and the shared library viewed in isolation does require
>>    the daemon be running to do anything useful.
>> 
>> 2. Weaken the dependency between the shared library and the daemon so that
>>    the shared library can be installed without the daemon even though it's
>>    objectively useless in that situation because it's the easiest and
>>    least annoying way to let the application be installed without the
>>    daemon, and that's the goal.  The shared library is usually tiny and
>>    causes no problems by being installed; it just doesn't work.
>> 
>> 3. Weaken the dependency between the application and the shared library,
>>    which means the application has to dynamically load the shared library
>>    rather than just link with it.  This is in some ways the most "correct"
>>    from a dependency perspective, but it's annoying to do, introduces new
>>    error handling cases in the application, and I suspect often upstream
>>    will flatly refuse to take such a patch.

> Unless I have misunderstood, I think you may have missed another option:

> 4. Let the leaf application declare the appropriate dependency on the
>    daemon, because the application writer/packager is in the best position
>    to know how important the functionality provided by the daemon is to the
>    application. This could be considered to be option 2b, and a "suggests"
>    dependency of the library on the daemon may still be appropriate.

I was thinking of this as a special case of 2, but yes, it's a
sufficiently common special case that it's worth calling out on its own.

I'm not sure that this whole discussion belongs in Policy because it's
very hard to make policy recommendations here without a lot of
case-specific details, but a section in the Developers Guide or some
similar resource about how to think about these cases seems like it might
be useful.  It does come up pretty regularly.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>