On Mo, Mai 31, 2010 at 11:18:55 (CEST), Adrian Knoth wrote: > On Sat, May 29, 2010 at 05:06:24PM -0400, Felipe Sateler wrote: > >> > Given the tons of C++ symbols in jackd2, I'd also suggest to make the >> > jackd1 package the official dev package and also the "donator" of the >> > symbols file. >> >> I'm quite confused by this. AFAIK, jack is a pure C API, so C++ >> symbols have no place in there. > > Yep. But jackd2 is implemented in C++, and these symbols somehow are > public or leak into the symbols file (also with -fvisibility=hidden).
May I summarize this as: "We intend to ship two implementations of jack: One that is used to build applications and one that we intend users to use as default". Is this a basis for consebsus? >> However, I understood from the last discussion that those are not >> really bogus, but are some sort of internal (server-lib) API, which is >> not allowed to be used by regular clients. Is this correct? > > Exactly. > >> Anyway, I really think that for jack it is much better to use a shlibs >> file. > > I'm completely fine with a shlibs file. Makes things a lot easier. Okay. Proposed wording for the release team: Dear Release Team, We, the pkg-multimedia team, would like to announce our intend to start a (new) jack transition. This includes a new upload of the package 'jack-audio-connection-kit', which provides the packages "libjack0" and libjack-dev". Details follow: There are several implementations of the jack audio connection kit. Besides the version which was included in Debian Lenny ('jackd'), there are also a number of different other implementations that partly offer a number of additional and (in our opinion) important features. All newer jack implementations are intended to be binary-compatible drop-in replacements the the original jackd. The last transition has 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 a 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 to depend on 'libjack0-0.116 | (>= libjack0-0.118+svn3796)'. This effectively defines a new virtual package 'libjack0-0.116' that is provided by any jack implementations 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 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 provides a meta package 'jackd' which points to the default jack implementation, which will be jackd2 for Debian. This creates the situation that we actually partially revert the last transition. However, we still consider jackd2 as the superior implementation for squeeze, so we need to introduce a new virtual package for the libjack0 library. We expect the actual rebuilds to be rather smooth, since the jackd1 implementation was tested extensively in Lenny and squeeze. We know that this is very very late for squeeze for which we apologize, but hope that it's not too late yet. Please give us a timeframe when we can start this transition with a new 'jack-audio-connection-kit' upload. on behalf of pkg-multimedia, ... proposed wording end. What do you think about this? With this explanation, I think the actual implementation in the source package should be straight-forward. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers