Bug#583916: Upcoming jack transition

[Reinhard Tartler]

On Mon, Jun 14, 2010 at 11:14:22 (CEST), Adam D. Barratt wrote:

> 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

Yes, that looks OK for me.

> 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.

Indeed, I agree.

> 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.

I don't think that will be a problem. adi, jonas, can you comment on this?


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