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

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to