On Sat, Jun 5, 2010 at 16:09:53 -0400, Felipe Sateler wrote: > On Sat, Jun 5, 2010 at 15:36, Julien Cristau <jcristau@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@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
Attachment:
signature.asc
Description: Digital signature