Bug#583916: Upcoming jack transition

[Reinhard Tartler]

On So, Jun 06, 2010 at 00:15:54 (CEST), Julien Cristau wrote:

> On Sat, Jun  5, 2010 at 16:09:53 -0400, Felipe Sateler wrote:
>
>> On Sat, Jun 5, 2010 at 15:36, Julien Cristau <jcristau at debian.org> wrote:
>> > 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.
>> 
> Your proposal talked about introducing a libjack-jackd2-0 and a
> libjack0-0.118+svn3796 package, AIUI.  I don't understand why the
> current libjack0 package can't stay.

Hm. maybe I missed something here. So your idea is to have the original
'jack1' package have the non-virtual package libjack0, right? The idea
was to make it easier in future to switch the jack implementation that
is used to build applications against. But I agree that this is not
really that important at this point. Moreover, I'm not even sure anymore
that we would want to do that, but that's future discussion, right.

>> > - 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.
>> 
> In that case I suggest changing libjack0 to:
> - kill the .symbols file
> - have the libjack0 package provide, replace and conflict with libjack0-0.116
> - have the libjack0.shlibs file point at 'libjack0 | libjack0-0.116' or
>   similar

Agreed.

> Then reverse deps can be gradually rebuilt.
>
> I'm not quite sure about the rest of the plan (switching the j-a-c-k
> package from one implementation to another one, introducing a
> jackd-defaults), it seems overengineered compared to leaving the current
> j-a-c-k package alone, and reintroducing jackd1 and its libjack
> alongside it.  Can you explain why you need all this?

The plan is to have 2 implementations of jackd2 in squeeze: jackd1 and
jackd2. Both badly need their 'own' implementation of libjack, while
regular applications don't care if they find libjack0 from jackd1 or
jackd2 at run time. [1]

For the default install, we want to install jackd2 by default as we
believe that it provides a superiour user experience. However, we want
to have all applications built against libjack0 from jackd1. Moreover,
upstream has indicated that they want to provide backports for future,
more featureful jackd1 packages on their website. Therefore I've
imagined a jack-defaults package that can be overriden in that
repository. A user would then only have to 'apt-get dist-upgrade' and
have its jackd2 replaced by the newer jackd1 implementation.

Moreover, this leaves us more options for squeeze+1, for which we
haven't decided which will be the "best" jackd implementation.

Do you still feel that this is overengineered?


[1] in fact, there may also be regular applications that might also
require "non-standard" features of jack that are not provided by the
0.116 ABI. In this case we expect such packages to install a more strict
shlibs.local file to express this.

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