linuxaudio.org

Excerpts from Arnold Krille's message of 2010-04-18 19:42:00 +0200:

quoted text
> 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

features.

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

quoted text
> > 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.

quoted text
>

> 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.
Regards,

Philipp
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev