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 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.

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?

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?

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.

 - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to