Bdale Garbee <bdale@gag.com> (06/02/2013): > I personally consider this a regrettable situation, and hope that for > jessie and beyond we can work out how to do this better. It is > unacceptable to me to "freeze" anything in sid for more than a week or > two at a time. Holding d-i's build dependencies static in unstable for > more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). > Sure seems like d-i is something we should build using the > components of the release it will be contained in and not > unstable... Why should that source package be special? Yes, it's cumbersome, it needs many uploads, if only because we need kernel fixes and improvements, along with fixes for its 100+ components. I'm happy to consider improvements to the process when we have time for that, meaning not 8 months into the freeze, but I'd be happy to receive an answer to the above question. > And I certainly don't think this is something we should even > consider changing at this late date in for wheezy release cycle! I concur. > I agree that we need to bring this current situation to closure > quickly so that the RC1 build of d-i for wheezy can proceed. We > seem to have three options: > > patch d-i to build successfully against the syslinux in sid And chase all regressions between syslinux 4 and 5? I'd rather not do that, especially given how tested and working patches are failing to deliver. Over the last few months on the d-i front, we've had 1 alpha, 4 betas; we would be throwing away the testing efforts of those 5 releases! > wiggle the d-i build processing to fetch syslinux from testing See above question, why should we special-case this build-dependency? > (re-)upload the previous syslinux version with a new epoch I don't see a better solution than this one. On a personal note, I'm unsure how we came up with a situation where a single maintainer can *actively* stall a release… Not caring about the release process put into place years ago is a thing. Stopping people from fixing problems created by such carelessness is another one… Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature