Gabriel M. Beddingfield wrote:
> On Sat, 17 Apr 2010, Jonas Smedegaard wrote:
>>> stop right here.
>>> the library and the daemon are tied together.
>>> the protocol between jackd and libjack is NOT fixed.
>>> (basically i consider it a mistake to even have libjack and jackd in
>>> different packages) but it might make sense to have that.
>> The separation of library and daemon is so that an application can
>> link against the library without forcing the daemon to be installed:
>> the JACK support might be optional for that application (without it
>> being a plugin that can be packaged separately from the main application.
> When you register with libjack, it will start the daemon if it is not
> already running. So, you can't have the library without the daemon.[*]
>From a distribution point of view - and just to clarify what I think
Jonas is trying to say - a lot of people will need the library but not
the daemon. E g FluidSynth (and many other applications) can use both
ALSA and JACK backends, so Debian ships FluidSynth with bindings to
libjack, although many users will just use the ALSA backend. These users
will have to install libjack but not the daemon.
And just linking to libjack doesn't cause jackd to start.
pkg-multimedia-maintainers mailing list