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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
