On Sat, Apr 17, 2010 at 12:37:45 (CEST), Adrian Knoth wrote: > Yesterday, somebody digged out Suse's announcement of our coordinated > distro approach for switching to jackd2. > > A lot has happened during the past hours on the mailing lists and via > IRC. > > Basically, the jackd1 camp isn't really happy. And some people think we > should really provide a choice which version to use. > > Foremost, jackd2 shouldn't be considered the successor of jackd1, but an > alternative implementation. Think of exim|sendmail|qmail.
perhaps it shouldn't have been named jackd2 in the first place then, uh? > So what do we have? > > jackd1 --> stable, containing jack_session (that's something new) > tschack --> jackd1 derivative with SMP support, jack_session > jackd2 --> C++ reimplementation, SMP, no jack_session yet, but on the > horizon, card reservation via DBUS (pulseaudio integration) > jackd3 --> upcoming C++ reimplementation of jackd1 I think this amount of variability is just madness. Do we really want to support any combination of application and jack daemon listed above? I feel we hardly manage to keep a single jack version in shape, and increasing the number of combinations to test is not going to make this easier. > If we can only have one jack version in Debian, we probably really use > jackd2 now, mostly because of card reservation. However, this would more > or less be a version lock-in. I wouldn't necessarily consider such a lock-in as bad, as it reduces the number of tests, see above. > Perhaps we should free ourselves and come up with a solution that allows > for different jackd implementations in Debian. Other distros can do > this, too. ;) > > We can't make libjack0 virtual, right? Can we put everything into a > single package, let's say jackd1 and jackd2, both containing the stuff > which is now present in libjack0, libjack-dev and the jackd package > itself? And then let them all Provide: jack-audio-connection-kit > or something like this. Technically, we could play tricks with the shlibs file, I'm doing such dirty tricks already in the FFmpeg package, and I think it could work with jack as well. For this, we would need to decide which implementation is going to provide the headers and library that shall be used for application packages at build time. The "trick" would be this: - rename the library package libjack0 to libjack0-jackd1 - make 'libjack0-jackd1' provide 'libjack0' - introduce other implementations in the same way, e.g., libjack0-jackd2 would provide libjack0 as well - install a (common) shlibs file in all implementations to make application packages refer to libjack0 in their dependencies - pray that we will never need to bump shlibs The obvious drawback of this madness is that we cannot use versioned dependencies anymore. E.g. newer jack libraries after 0.116.2 introduced some new symbols. If some application does not work with an earlier version than 0.116.2 of jack, then we cannot express that situation in terms of package dependencies anymore. In that case we need to rename the name of the virtual package, e.g., libjack0a and recompile the world! I don't know about the implementation of jackd1 vs. jackd2 or future implementation, but my impression of this whole mess makes me feel that something like this is not unlikely at all, despite the fact upstream is trying really hard to preserve both forward and reverse binary compatibility. And now a reality check: currently, libjack0's shlibs file looks like this: ,----[/var/lib/dpkg/info/libjack0.shlibs] | libjack 0 libjack0 (>= 0.118+svn3796) | libjackserver 0 libjack0 (>= 0.118+svn3796) `---- this means that we already declare that applications that have been built against squeeze's libjack won't work with lenny's libjack0. If this is really the case, then we have already lost. > We might even use alternatives. Could this work? the Debian science team is doing something very similar to this as well. The release team first had some concerns, but eventually agreed to this approach. I'd rather like to avoid it because of the reasons outlined above. > If this is too much trouble, we should stick to our jackd2 plans and > wait for jackd3 to come. this would only defer the problem to later, AFAIUI. I'm thinking about something like the nvidia vdpau approach: introduce a new abstraction lib, that checks at runtime for available real implementations and uses them then. But given that the jack API is not exactly trivial, this might be infeasible as well :-( > However, there has already been one good result: somebody is coding > jack-session for jackd2 now, because if we really move to jackd2, it > wouldn't make sense to only have it in jackd1. How about implementing a pulseaudio module that implements the jack ABI? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers