Bug#583916: Upcoming jack transition

[Felipe Sateler]

On Sat, Jun 5, 2010 at 15:36, Julien Cristau <jcristau at debian.org> wrote:
> 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?

Because there can be only one package of a given name... unless I'm
misparsing your question.

> - I understand you want to allow different jackd implementations to
>  coexist.  Do we really need 2 implementations of libjack as well?

Yes. The server and the library have an internal API that is not
guaranteed to be compatible across any kind of release. So these two
must be the same upstream version.

> - 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?

I believe the symbols file is borked. Client applications are only
allowed to assume functions defined in 0.116 to exist. Extra symbols
are defined as weak, and clients intending to use them must check for
their availability. Clients assuming such symbols exist are broken
according to upstream.

So... libjack *can* have extra symbols added after the 0.116 API, and
it *can* have extra symbols for use for the server. Client
applications cannot assume they exist, though.

-- 

Saludos,
Felipe Sateler