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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
