Rekindle jack implementation swapping discussion

[Reinhard Tartler]

On Mo, Mai 31, 2010 at 11:18:55 (CEST), Adrian Knoth wrote:

> On Sat, May 29, 2010 at 05:06:24PM -0400, Felipe Sateler wrote:
>
>> > Given the tons of C++ symbols in jackd2, I'd also suggest to make the
>> > jackd1 package the official dev package and also the "donator" of the
>> > symbols file.
>> 
>> I'm quite confused by this. AFAIK, jack is a pure C API, so C++
>> symbols have no place in there. 
>
> Yep. But jackd2 is implemented in C++, and these symbols somehow are
> public or leak into the symbols file (also with -fvisibility=hidden).

May I summarize this as:

  "We intend to ship two implementations of jack:
One that is used to build applications and one that we intend users to
use as default".

Is this a basis for consebsus?

>> However, I understood from the last discussion that those are not
>> really bogus, but are some sort of internal (server-lib) API, which is
>> not allowed to be used by regular clients. Is this correct?
>
> Exactly.
>
>> Anyway, I really think that for jack it is much better to use a shlibs
>> file.
>
> I'm completely fine with a shlibs file. Makes things a lot easier.

Okay.


Proposed wording for the release team:

Dear Release Team,

We, the pkg-multimedia team, would like to announce our intend to start
a (new) jack transition. This includes a new upload of the package
'jack-audio-connection-kit', which provides the packages "libjack0" and
libjack-dev".

Details follow:

There are several implementations of the jack audio connection kit.
Besides the version which was included in Debian Lenny ('jackd'), there
are also a number of different other implementations that partly offer a
number of additional and (in our opinion) important features. All newer
jack implementations are intended to be binary-compatible drop-in
replacements the the original jackd.

The last transition has 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 a 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 to depend on 
   'libjack0-0.116 | (>= libjack0-0.118+svn3796)'. This effectively
   defines a new virtual package 'libjack0-0.116' that is provided by
   any jack implementations 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 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 provides a meta
   package 'jackd' which points to the default jack implementation,
   which will be jackd2 for Debian.


This creates the situation that we actually partially revert the last
transition.  However, we still consider jackd2 as the superior
implementation for squeeze, so we need to introduce a new virtual
package for the libjack0 library. We expect the actual rebuilds to be
rather smooth, since the jackd1 implementation was tested extensively in
Lenny and squeeze.

We know that this is very very late for squeeze for which we apologize,
but hope that it's not too late yet.  Please give us a timeframe when we
can start this transition with a new 'jack-audio-connection-kit' upload.

on behalf of pkg-multimedia,
   ...


proposed wording end.


What do you think about this? With this explanation, I think the actual
implementation in the source package should be straight-forward.



-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4