On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote: > On Sat, Apr 17, 2010 at 02:31:46PM -0400, Felipe Sateler wrote: > >On Sat, Apr 17, 2010 at 09:25, torbenh <torb...@gmx.de> wrote: > >> > >>hi... > > > >Hi Torben. (I'm CCing you because I don't know if you are subscribed). > > Oh, good point. > > Torben: Please see my earlier response to your post. And please > when posting to Debian lists mention explicitly if you want to be > cc'ed on responses, as our default list policy is to only respond to > the list.
i am subscribed. > > > >>its fine if the default is jack2. but please leave the door open > >>for people who have problems with jack2 and are better off with > >>tschack. > > > >There is additional burden to packaging several versions of jack. > >Unless someone takes that burden and packages another version of > >jack, there is no point in making the debian package more complex. > >Are there debian packages of these other versions of jack around? tschack is based on jack1. in its current state it has the same set of dependencies. and would build fine with the exact same packaging method jack1 is currently built with. i might add the soundcard allocation in the future. (which adds dbus dependency) but i am not completely sure if i want to do that, since it could also be done using scripts. > > Right now we have a packaging of jackd1 (or jack1 - not sure what is > the most proper name for it) in ustable, and jackd2 in experimental. > > Yes, they are both based on same packaging VCS source, but it is not > too late for us to revert that. > > When we decided to switch to jackd2 it was (at least for me) based > on the assumption that jackd1 was old code being replaced by jackd2. > Now that this has shown not to be true, it makes good sense for me > that we maintain multiple branches - and that we start by *not* > replacing jackd1 with jackd2 but instead keep the old code and > instead focus on transitioning to making the core name be a virtual > package and none of the implementations "owning" it. > > > >>we (upstream) will make sure they are binary compatible. all > >>symbols added since jack-0.116 are mandated to be weak. if there > >>are any issues with binary compatibility these are bugs. > > > >I'm not sure how weak symbols help binary compatibility. If I > >understand weak symbols correctly, it enables an application to > >detect if certain symbols are available and make use of them. How > >does that ensure that an application built against one version is > >compatible with another? because the core ABI of jack wont change anymore. there will only be additional optional symbols added. > > Not an answer (as you know I am incapable of doing so), but I > propose to stick to jackd1 as the default/only library for other > packages to rely on until the rerlease of Squeeze, and only offer > alternative daemons (and eventually - most likely post-Squeeze - > alternative libraries too) if they do not interfere with that. stop right here. the library and the daemon are tied together. the protocol between jackd and libjack is NOT fixed. (basically i consider it a mistake to even have libjack and jackd in different packages) but it might make sense to have that. still you MUST ALWAYS lock the a jackd and libjack package together. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > _______________________________________________ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- torben Hohn _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
