Bug#583916: Upcoming jack transition

[Adam D. Barratt]

On Mon, June 14, 2010 06:49, Reinhard Tartler wrote:
> 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.
[...]
>> 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?

What I meant was, could we do something along the lines of:

* upload new j-a-c-k package and whatever other sourceful changes are
required
* get the above built everywhere and migrated to testing asap
* binNMU libjack0's r-deps a few at a time, letting them migrate to
testing as and when they're ready and skipping any that will require
rebuilds for other transitions anyway

This would be much easier to fit in around other transitions than having
to rebuild all of the r-deps before any of them could transition.  From a
quick look, the only potential issue with the j-a-c-k upload itself I can
see is that it build-depends on python; however, as it doesn't produce any
python modules and only appears to have a runtime dependency on the python
package, I'm not sure this actually causes any problems in practice.

Regards,

Adam