Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, bl...@debian.org,
debian-wb-t...@lists.debian.org
Luca Boccassi and I have been preparing stable and oldstable updates for
debootstrap so that the transition described in DEP-17 can continue.
Because DEP-17 involves changes to trixie/sid chroots' bootstrap
procedures, the updated debootstrap needs to be deployable to every
official buildd, and we've been told that (old)stable point releases
are the preferred way to achieve that.
When Luca asked how many suites we needed this change in, we were hoping
the answer would be stable only, and maybe oldstable (which is still
in its 1 year of overlapping support from the security team and DDs
in general).
However, if I understand correctly, Luca has been told that some official
mips64el buildds are running mipsel user-space on mips64el hardware which
only works with the buster kernel, and therefore those official buildds
are still stuck on buster, meaning we also need to prepare a buster
version of debootstrap and get it into Debian 10 LTS via buster-security.
Is this true?
>From the point of view of the project having control over its own future,
I would have hoped that official Debian infrastructure would only be using
suites that are supported by Debian as a whole, rather than handing over
control and responsibility to the Debian-LTS subproject.
Also, from the point of view of continued development of testing/unstable,
I would have hoped that packages in testing/unstable could safely
assume that they will run on at least the kernel from stable (or maybe
oldstable for a short time after a new stable release), following our
usual "skipping a release is unsupported" rule. Obviously if the buildds
are running on an oldoldstable kernel, any mips64el package that might
be used at compile-time or for build-time tests will be unable to make
that assumption.
Please could someone with knowledge of the buildds clarify the situation?
If our official buildds for a release architecture are unable to run on
either the stable or oldstable kernel, I think that raises some important
questions about suitability for inclusion in future releases.
Thanks,
smcv
