On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote: > The last transition 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 an 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 depend on > 'libjack0-0.116 | libjack0-0.118+svn3796 (>= 1:0.0116)' (or similar). > This effectively defines a new virtual package 'libjack0-0.116' that > is provided by any jack implementation 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 a 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 generates a meta > package 'jackd' which points to the default jack implementation, > which will be jackd2 for Debian. > 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? - I understand you want to allow different jackd implementations to coexist. Do we really need 2 implementations of libjack as well? - 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?
Overall this looks like a lot of churn, late in the release cycle, for an end result which seems quite close to the current situation. Cheers, Julien
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers