[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Policy: should libraries depend on services (daemons) that they can speak to?
From:       Sune Vuorela <nospam () vuorela ! dk>
Date:       2024-01-08 8:21:08
Message-ID: ungb9k$b0d$1 () ciao ! gmane ! io
[Download RAW message or body]

On 2024-01-07, Ansgar <ansgar@43-1.org> wrote:
> 1. libpulse0 & friends
> ----------------------

> If the answer is "yes", this would result in an application that can
> output audio via Pulseaudio or Jackd and linking the respective
> liubraries pulling in *both* Pulseaudio and Jackd (and possibly other
> sound servers as well).

I'm a bit .. it depends. But it might end up being delegated to the
applications to do it manually maybe.

Assuming an audio providing program (netradio streamer or something)
that just does pulseaudio. No backends. no configuration. Just pulse.

I would not expect users to figure out that a Suggests: pulseaudio was
the missing bit needed to get the application to actually work.

On the other hand

> 3. The general case
> -------------------

I'm currently investigating an upstream bug report from a sister
distribution.

A document reader links thru various intermediate steps to libspeech2, a
library from src:speech-dispatcher to talk to speech-dispatcher daemon
to do text-to-speech. And libspeech2 (at least thru the intermediates)
ends up not giving me an easy failure to act upon.

How do the distribution maintainer of the document reader ensure that 
the users know that they need speech-dispatcher around for that to work?


Maybe the question is also a bit .. "it depends". 
Assuming 10 different sound servers, one might be the one we as a
distribution considers the default. Maybe the default one should have
libfoo: Recommends: foo.
and the non-defaults should have
libbar: Suggests: bar

So that users actually likely get a system that works?

I guess it is a tradeoff between extra-cruft-on-systems and
likely-that-systems-work, and we need to draw a line somewhere.

I might also be slightly biased towards adding slightly extra cruft on
systems to ensure they work because of the package collection I'm
involved in (KDE and friends) as opposed to people maintaining packages
mostly used by server administrators, maybe even container-heavy server
administrators.

/Sune

[prev in list] [next in list] [prev in thread] [next in thread]