Question: depending on multiple sound server libraries

[Jonas Smedegaard]

On Thu, Mar 24, 2011 at 11:41:09AM +0100, Johannes Weißl wrote:
>I have a question about dependency of packages on multiple sound server 
>libraries. The cmus [1] audio player has multiple output plugins, like 
>roar, alsa, pulse, ao, etc. The package used to depend on all those 
>libraries, but then users complained [2] because libroar1 recommends 
>the roaraudio server. Although this is fixed now (libroar1 only 
>suggests roaraudio), I wonder what would be the best solution for this 
>problem:
>
>a) make cmus-plugin-* packages for all plugins which require additional
>   dependencies (like in sox)
>b) only make cmus-plugin-* packages for "rarely" used plugins
>   (e.g. roar) and depend on e.g. libpulse0
>c) depend on (almost) all dependencies
>
>I know normally a) would be the way to go, but since the player is
>really small I don't know if it's worth to split it into 7+ packages...
>What do you think?
>
>The maintainer asked me to forward my question to the list. Thanks for
>your help!

I disagree that there is a single "normal" approach.  All of above are 
normal.  And I agree that size of the package is relevant too when 
judging.

Debian generally aims at enabling most possible features.  That is good 
initially, to challenge maturity of features and to ensure least 
possible features conflict with each other when enabled concurrently.

When possible and sensible, it makes sense to add choice of avoiding 
some of those features.  One approach is "flavored" packages (i.e. 
faster (optimized for certain hardware) or lightweight (avoiding certain 
features).  But even if upstream codes in a nice flexible way (e.g. 
using runtime loadable modules) it might not be sensible for Debian to 
make use of it.

Example: I have maintained a "non-X11" variant of a graphics library for 
some years, due to it being popular for web services and its support for 
the infrequently used graphics format Xpm caused it to pull in 70MB of 
X11 libraries.  But now that Xorg have been better structured and 
packaged, the pulled-in X11 libraries are down to less than 10MB (I 
guess - haven't inspected closely recently) I consider dropping that 
flavoring both to simplify maintainance (not only for me - dependent 
packages are obviously affected by the flavoring too) and to reduce the 
number of packages in the Debian archive.

So there is no simple answer.  Not even a simple answer for "when is a 
package too small for splitting up".


For the concrete case, I suggest to keep it simple and package 
everything together.  Only if it largely affects actual use it is 
sensible to look at splitting up packaging - or more likely: look into 
better ways to solve the problem, like repackaging Xorg as in my example 
above, or improving package relations as in the roar daemon case.


Hope that helps.

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20110324/89d695d9/attachment.pgp>