Russ Allbery <rra@debian.org> writes:
> In practice, at least for the last couple of release cycles, we freeze
> unstable for non-leaf packages during the release freeze because otherwise
> it's too difficult with our current infrastructure to finish the
> release.
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! Sure seems like d-i is
something we should build using the components of the release it will be
contained in and not unstable... but I haven't tried to think hard about
what that might imply that's problematic. And I certainly don't think
this is something we should even consider changing at this late date in
for wheezy release cycle!
> Given that, I think it makes sense to, as
> Daniel mentioned, make it rather explicit that, yes, unstable is frozen
> for non-leaf packages until we complete the release. And, in this
> specific case, to revert the syslinux update in unstable (and hopefully
> upload to experimental) so that we're not building d-i against a package
> that isn't part of the release.
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
wiggle the d-i build processing to fetch syslinux from testing
(re-)upload the previous syslinux version with a new epoch
The first requires a patch that actually works, and there is at least
one assertion that the patch Daniel pointed to does not. The second I
can't speak to the complexity of since the last time I looked at d-i was
just before the last stable release. The third is "easy" to accomplish
but requires agreement from the maintainer or a TC vote to overrule him.
I'm relatively unavailable for the next 24 hours. Hopefully by then
further investigation and/or discussion will help make it clear which of
the above options we should pursue.
Bdale
Attachment:
pgpKgEdOMvXSM.pgp
Description: PGP signature