Bug#583916: Upcoming jack transition

[Julien Cristau]

On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote:

> The last transition switched the jack-audio-connection-kit package
> from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of
> jackd in C++ with SMP support. Most importantly however, is an added
> feature that improves interoperability with pulseaudio.  For this
> reason, we decided to make this version the default version for Squeeze.
> 
> During testing, however, we discovered that this transition has been and
> still is a bit problematic.  Besides some more or less known bugs in
> 'jackd2', it exposes a lot of additional (internal, C++ only) symbols,
> with which we are not comfortable at all.  Moreover, we have been
> approached by upstream(s) with concerns that our current package does
> not make it easy for 3rd parties (may it be upstream or backports.org)    
> to provide replacement packages for other jackd implementations.
> 
> For this reason, we propose to:
> 
>  - revert the 'jack-audio-connection-kit' package to the jackd1
>    implementation
> 
>  - make this package the provider of libjack-dev, however the actual
>    daemon will be packaged as 'jackd1' (currently jackd)
> 
>  - create a shlibs file that makes application packages depend on
>    'libjack0-0.116 | libjack0-0.118+svn3796 (>= 1:0.0116)' (or similar).
>    This effectively defines a new virtual package 'libjack0-0.116' that
>    is provided by any jack implementation that claims to be binary 
>    compatible with the 0.116 release of the original jack
>    implementation.
> 
>  - have all packages that are linked against libjack recompiled to pick
>    up the new shlibs
> 
>  - introduce the jackd2 implementation as a new source package 'jackd2'.
>    The binary package name of this jack daemon will be 'jackd2', the
>    library package will be 'libjack-jackd2-0' and (of course also)
>    provide 'libjack0-0.116'.
> 
>  - introduce a new source package 'jackd-defaults' that generates a meta
>    package 'jackd' which points to the default jack implementation,
>    which will be jackd2 for Debian.
> 
So I have a few questions about this plan:
- if all implementations of libjack are binary-compatible, then why do
  we need to change the package name when changing implementations of
  libjack?
- I understand you want to allow different jackd implementations to
  coexist.  Do we really need 2 implementations of libjack as well?
- related to this, the libjack0.symbols file currently has things like
  'jack_client_kill_thread at Base 1.9.5~dfsg-13' which suggest that it is,
  actually, not completely compatible with other implementations (a
  quick check suggests that nothing out of the jack-audio-connection-kit
  source package uses these additional symbols, but..)
- many packages apparently depend on symbols labelled 0.118.0 or later
  in the symbols file, how does that fly with a 0.116 jackd1?

Overall this looks like a lot of churn, late in the release cycle, for
an end result which seems quite close to the current situation.

Cheers,
Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100605/49203267/attachment-0001.pgp>