Yesterday, somebody digged out Suse's announcement of our coordinated
distro approach for switching to jackd2.

A lot has happened during the past hours on the mailing lists and via

Basically, the jackd1 camp isn't really happy. And some people think we
should really provide a choice which version to use.

Foremost, jackd2 shouldn't be considered the successor of jackd1, but an
alternative implementation. Think of exim|sendmail|qmail.

So what do we have?

jackd1 --> stable, containing jack_session (that's something new)
tschack --> jackd1 derivative with SMP support, jack_session
jackd2 --> C++ reimplementation, SMP, no jack_session yet, but on the
           horizon, card reservation via DBUS (pulseaudio integration)
jackd3 --> upcoming C++ reimplementation of jackd1

If we can only have one jack version in Debian, we probably really use
jackd2 now, mostly because of card reservation. However, this would more
or less be a version lock-in.

Perhaps we should free ourselves and come up with a solution that allows
for different jackd implementations in Debian. Other distros can do
this, too. ;)

We can't make libjack0 virtual, right? Can we put everything into a
single package, let's say jackd1 and jackd2, both containing the stuff
which is now present in libjack0, libjack-dev and the jackd package
itself? And then let them all Provide: jack-audio-connection-kit
or something like this.

We might even use alternatives. Could this work?

If this is too much trouble, we should stick to our jackd2 plans and
wait for jackd3 to come.

However, there has already been one good result: somebody is coding
jack-session for jackd2 now, because if we really move to jackd2, it
wouldn't make sense to only have it in jackd1.


mail: a...@thur.de      http://adi.thur.de      PGP/GPG: key via keyserver

pkg-multimedia-maintainers mailing list

Reply via email to