Bug#583916: Upcoming jack transition

[Reinhard Tartler]

On Sat, Jun 12, 2010 at 16:57:52 (CEST), Adam D. Barratt wrote:

> On Mon, 2010-05-31 at 18:39 +0200, Reinhard Tartler wrote:
>> This creates the situation that we actually partially revert the last
>> transition.  However, we still consider jackd2 as the superior
>> implementation for squeeze, so we need to introduce a new virtual
>> package for the libjack0 library. We expect the actual rebuilds to be
>> rather smooth, since the jackd1 implementation was tested extensively in
>> Lenny and Squeeze.
>> 
>> It appears that 93 source packages will need to be binNMUd as part of 
>> this transition.
>> 
>> We know that this is very very late for squeeze for which we apologize,
>> but hope that it's not too late yet.  Please give us a timeframe when we
>> can start this transition with a new 'jack-audio-connection-kit' upload.
>
> It is indeed very late in the cycle to be introducing such a transition.
>
> I'm not quite clear where things were up to after the discussion of
> Julien's suggestions, but we're trying to tie down as final a possible a
> set of remaining transitions for Squeeze and this does seem like it
> would cause us a significant number of rebuilds of packages that in some
> cases will need to be rebuilt for other transitions anyway and aren't
> always the smoothest to build (xmms2/armel had problems around the time
> we were trying to get the directfb transition block migrated, for
> example).

I see.

> Is there a solution which would allow us to perform a gradual rebuild of
> involved packages without potentially blocking other transitions?

The transition does not need to be finished before some other transition
starts because we intend to retain the package 'libjack0' as non-virtual
package so that dependencies on this remain resolvable all the time.

Is this what you've asked for or did I miss something?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4