"Theodore Ts'o" <ty...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
