[LAD] distros migrating to JACK2?

Philipp hollunder at lavabit.com
Sun Apr 18 18:15:12 UTC 2010

Excerpts from Arnold Krille's message of 2010-04-18 19:42:00 +0200:
> On Sunday 18 April 2010 00:14:31 Philipp wrote:
> > Excerpts from Arnold Krille's message of 2010-04-17 23:15:11 +0200:
> > >...
> > > That way your favourite
> > > music player can have an output plugin that looks for jack and if that is
> > > not running, looks for pulse and finally choose direct alsa for
> > > playback...
> > I don't see why jack needs to be splitted for this, it works just fine
> > with jack installed in a single package. Example Audioplayer: Aqualung
> Because libjack (the same as libpulse) will start jackd if its not running. 
> Unless that server-package is not installed:-) That is why these two should be 
> separate. Sometimes you really don't want to run jack. But the 
> developers/packagers of that music-player don't have a separate plugin and 
> package for the jack-output. So you need the jack-lib to install the player. 
> But you don't need the jack server to run that music player...

Jack isn't started automatically in every case, it depends on the
app, and afaik very few do it.

So you're effectively only reducing the size of the packages the user
has to install as dependencies of the music player.
I do package myself a little bit, and the package management system is
probably a few orders of magnitude simpler than apt, and so is the
packaging, but the basic issues are the same everywhere.
You always have to find the 'right' balance between features and
dependencies. Simplified, users want every feature but no dependency.
There's no way to do it, so you have to find a balance. The debian-like
system compiles the package with every feature but the user only needs
to install half the dependencies, and some more if he wants to use the
The gentoo-/arch-like system allows the user to easily recompile and
install the package with whatever features he wants.

It's maybe a bit simplified, but that's how I see it.
I don't know how much trouble the absence of part of the program causes.
In my experience it can be quite bad, but there are some notable cases
where the developers did a good job. Example: moc
A music player that can be compiled with wavpack support, but if wavpack
is missing at runtime there's no problem, you simply can't load wavpack
files into it. I wish more programs would work like that.

> > In general it seems to be a matter of taste, and while debian folk sees
> > benefits in it others simply don't think it's worth the trouble.
> Hm, which distribution apart from gentoo do you know that has jacks libs and 
> server/apps in one package?

Arch Linux, the one I'm using these days.

> > IMHO it simply shouldn't get in the way.
> Thats exactly the not-so-simple point: Some developers make it very hard for 
> users and packagers...
> Have fun,
> Arnold

My motto is: "Work with upstream."
So far my experience was great in that respect. Most developers are
happy about feedback and willing to help resolve packaging issues.

On a sidenote, I don't want to start a flamewar and discuss the merits
of different distributions. The differences are huge in some areas and
all have their benefits. While I switched from a debian derived distro
(ubuntu) and am very happy with the benefits Arch Linux offers I really
respect debian for the idealism and the broad spectrum the project tries
to cover.


More information about the Linux-audio-dev mailing list