Re: Policy: should libraries depend on services (daemons) that they can speak to?
"Theodore Ts'o" <tytso@mit.edu> writes:
> I'll argue that best practice is that upstream show make the shared
> library useful *without* the daemon, but if the daemon is present,
> perhaps the shared library can do a better job.
Eh, I think this too depends on precisely what the shared library is for.
The obvious example of where this doesn't work is when the shared library
is a client for a local system service, and its entire point is to
dispatch calls to that service, but the library and service combined
implement an optional feature in some of the programs linked to it.
I think that's a relatively common case and the sort of case that provokes
most of the desire to not make shared libraries have hard dependencies on
their services. There are a bunch of services that do not support (and
often would never reasonably support) network connections to their
underlying services. An obvious example is a library and service pair
that represents a way to manage privilege escalation with isolation on the
local system. You cannot make the shared library useful without the
daemon because the entire point of the shared library and daemon pair is
to not give those permissions to the process containing the shared
library.
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.
We do 2 a lot because it's pragmatic and it doesn't really cause any
practical problems, even though it technically means that we're not
properly representing the dependencies of the shared library. We in
general try not to do 1 for reasons that I think are sound. Minimizing
the footprint of applications for people who don't want optional features
is something that I personally value a lot in Debian.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: