Bug#583916: Upcoming jack transition

[Julien Cristau]

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.

> > - 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.
> 
OK.

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

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?

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/20100606/f39382c9/attachment.pgp>