packaging jack...

[Jonas Smedegaard]

On Sat, Apr 17, 2010 at 02:31:46PM -0400, Felipe Sateler wrote:
>On Sat, Apr 17, 2010 at 09:25, torbenh <torbenh at 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.


>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100417/15d7fa21/attachment.pgp>