Bug#583916: Upcoming jack transition
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).
Is there a solution which would allow us to perform a gradual rebuild of
involved packages without potentially blocking other transitions?
Regards,
Adam
Reply to: