On Wed, Mar 17, 2010 at 01:29:31PM -0400, Eric Dantan Rzewnicki wrote:
On Wed, Mar 17, 2010 at 06:24:10PM +0100, Jonas Smedegaard wrote:
On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote:
On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard <d...@jones.dk> wrote:
On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote:
Also, if my understanding is correct, jack2 is ABI compatible with
jack1, so no library transition is needed.
That was my impression too.  If so, why don't we ship *both*?
Let's rename jackd → jackd1, package jackd2, and let both binary
packages provide jackd as a virtual package.
There are a bunch of packages depending on jackd (>= something), so
this approach would break those apps.
Ah, good point.
A metapackage depending on jackd1 | jackd2 would work, though.

I find a metapackage an inelegant approach.

My suggestion is then to keep jackd as-is for now but

  a) introduce a new jackd2
     (hopefully ready for inclusion with Squeeze),

It is already in experimental (as jackd 1.9.4+svn3842-2).

The code, yes. But with source package name identical to older code so cannot coexist with older jackd in same distribution release.

What I propose is to ship the new code as a separate source package and a separate binary package. The binary package will conflict with the similar binary package provided by the older code (at least at first), and probably no binary library packages will be provided either.

My proposal is to package jackd2 _distributable_ in parallel to existing stable jackd1 but not _installable_ in parallel.

 - 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