Bits from the Release Team: What should go into squeeze?

[Jonas Smedegaard]

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 <dr at 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
-------------- 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/20100317/1a6f4028/attachment.pgp>