packaging jack...

Jonas Smedegaard jonas at jones.dk
Tue Apr 20 08:17:42 UTC 2010


On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:
>On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:

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

Ok, my mistake.

Let me then adjust and refine my proposal (main point is the same):

  1. Release src:jack-audio-connection-kit to unstable:
     * revert to track only jackd1
  2. Initially release src:jackd2:
     * jackd2 conflicts/replaces/provides jackd
     * libjack0-jackd2 conflicts/replaces libjack0
     * libjack0-jackd2 provides libjack-0.116.0
     * libjack-jackd2-dev conflicts libjack-dev
     * Big fat warning to use -dev package only privately
  3. Initially release src:tchack, like jackd2
  4. Update jack-depending packages after testing that it works:
     * Add libjack-0.116.0 as fallback-dependency for libjack0

  4. Release jackd1 to experimental, with libjack0 providing 
     virtual package libjack-0.116.0
  5. Repackage jackd1 to experimental, with libjack0 providing 
     virtual package libjack0-0.116.0
  4. Release jackd1 to experimental, with libjack0 providing 
     virtual package libjack0-0.116.0
  5. Maybe add -dev packages for jackd2 and tchack later

The main thing in above is to stick with jackd1, treating it as the 
reference implementation that other implementations match but do not 
override (they do not provide libjack-dev!).  That means no dependent 
package needs rebuilding, and rebuilds cannot accidentally shift to 
linking against another implementation with potentially different API. 
If alternate implementations turn out to not be stable enough as runtime 
drop-in replacements, they can thus be ripped out of Squeeze late in the 
game, as no other packages depend on them.

It was suggested to discuss the introduction of the virtual 
libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
coordinated only amongst 3 packages that are all maintained by us.  But 
if someone finds it relevant and have the time available to take such 
discussion then it certainly won't hurt (the only thing it hurts is 
time).

Later it might make sense to try support officially linking against 
alternate implementations. If that works out, it might make sense to 
repackage jackd1 similar to the others, so as to treat all 
implementations as equal competitors.  But that is post Squeeze IMO.


If noone objects to this proposal, I will start working on it as soon 
aas I find time (probably starting in a week from now).


  - 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/20100420/65edb33c/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list