The (uncalled for) toolchain maintainers roll call for stretch
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that the release criteria are somehow "reset" for the stretch
release, and not copied from previous release decisions.
GNU toolchain (GCC / binutils)
------------------------------
GCC upstream has the notation of primary and secondary platforms, with the
commitment to fix issues on these platforms [1], [2]. Debian architectures
within the set of these platforms are:
- aarch64-none-linux-gnu (starting with GCC 7)
- arm-linux-gnueabi
- i686-pc-linux-gnu
- powerpc64-unknown-linux-gnu
- x86_64-unknown-linux-gnu
- s390x-linux-gnu
Release architectures missing in the primary and secondary platforms:
- armhf
- mips*
- powerpc
- ppc64el
As you see with arm64, new architectures become primary or secondary platforms
only after a while, so that may explain the absence of
powerpc64le-unknown-linux-gnu.
The arm-linux-gnueabi is not that well defined, so it may include the hard float
variant as well. However Debian default to armv4t, while the default
configuration for upstream is armv5. However with the selected defaults
Debian's libstdc++::future module is not complete and causes build failures on
this architecture (same for sparc).
Uncovered by the upstream primary and secondary platforms are the mips*
architectures and powerpc. For the uncovered archs I would expect somehow more
and pro-active Debian maintenance, however I fail to see this happen.
- see the history of ftbfs on the buildd page of the gcc-snapshot package
- see the status of the gcc-6 package for the pre-release uploads
- see the number of RC issues for binutils which came up with 2.27,
some still open.
- Toolchain packages are not watched by porters, and I can't track
every regression myself, however this is not done well by porters.
On the recent Porter's call I didn't see any toolchain support for the powerpc
architecture. For the mips* architectures we apparently have five or more
active toolchain maintainers. I very much doubt that view. From my point of
view these architecture would be perfect candidates for partial architectures,
and until then should be removed from the set of the release architectures. For
mips* that shouldn't be no news; please see my comments regarding both the
toolchain and buildd status since at least DebConf 12 (release meetings during
DebConfs).
Java/OpenJDK
------------
For the stretch release openjdk-8 will be fine as the default java
implementation. For buster, gcj (to be removed in GCC 7) won't be available
anymore, and we'll end up with architectures without a java implementation. At
the same time I'd like to consider to stop providing OpenJDK zero builds,
leaving powerpc and mips* without a java implementation as well (currently not
building for openjdk-9). armhf (not armel) and s390x have Hotspot ports underway.
Other toolchains
----------------
- clang/llvm not available on armel since 3.8.
- fpc not available on powerpc anymore (may have changed recently)
- mono not available more on powerpc
Being demoted as a release architecture certainly is not a nice thing, and
looking at past demotions, these were not done very coordinated, not allowing
builds in the ports archive for some months. It would be good to find some
middle-ground such that a port's demotion isn't a final thing, and it has a
chance to become a release architecture again, maybe even as a partial
architecture if we can define the meaning of such a thing.
Matthias
[1] https://gcc.gnu.org/gcc-6/criteria.html
[2] https://gcc.gnu.org/gcc-7/criteria.html
Reply to: