Re: Policy: should libraries depend on services (daemons) that they can speak to?
On Mon, Jan 08, 2024 at 11:18:09AM +0000, Simon McVittie wrote:
> On Mon, 08 Jan 2024 at 08:21:08 -0000, Sune Vuorela wrote:
> > Maybe the question is also a bit .. "it depends".
> ...
> > So that users actually likely get a system that works?
>
> I think the fact that we argue about this every few years, with no simple
> conclusion, is adequate evidence that the answer is "it depends". We're
> balancing two competing factors: "make the system work by default" implies
> that *something* needs to be responsible for pulling in required services
> at least some of the time, while "make the system flexible" implies that
> we should not be pulling in all of the services all of the time.
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.
For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.
So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.
Of course, that's an upstream design consideration, and not all
upstreams are so.... forward looking... in their design.
>
> Meanwhile, some distributions are more opinionated than Debian,
> have chosen a distro-wide preferred implementation for each swappable
> component, and make it quite difficult to exclude those components or
> swap them for alternatives. We probably don't want to do that either.
Well, right. And if the distribution's primary market is enterprise
customers, such that using an Enterprise Resource Planning system is
highly likely (even if said ERP is proprietary softare sold by a very
large German company), you might decide that it's worthwhile to
install uuidd by default, especially since it's a relativelty small
daemon. But if you're a distribution that thinks that every last
kilobyte matters, because you might be used in a docker context (for
example), then you mnight want to make different choices.
Cheers,
- Ted
Reply to: