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 <jcris...@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_thr...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
