On Sat, 15 Aug 2026 at 20:13:32 +0900, Simon Richter wrote:
On 8/15/26 18:43, Simon McVittie wrote:
armel, armhf, s390 and powerpc all have/had newer-but-backward-
compatible CPUs that could run them (armhf/arm64, arm64, s390x and
ppc64 respectively), but they never had a significant amount of
binary-only software that we can run, and the 64-bit time_t
transition has broken their ABIs anyway, so they don't seem
practically useful as partial architectures.
armel, armhf and powerpc are useful as partial architectures because
the hardware still exists and is still used, but the shifting baseline
for the "modern" variant drops support for them.
It could potentially be useful to have a reduced package-set on armel,
armhf and (in -ports) powerpc, but this isn't a partial architecture in
quite the same way that i386 would want to be, because it's a different
subset of packages that is interesting. That's part of the reason for my
concern about premature generalization - it doesn't necessarily make
sense to exclude the same list of packages from i386 that are excluded
from armhf.
On i386 with the use-cases as stated in the trixie release notes, we no
longer need kernels, bootloaders, init systems, most system services,
and generally most packages that aren't libraries or user-space drivers.
The list of packages that we *do* need is quite small!
On armel and armhf, if you have an ARMv8 machine, you should just run
arm64 on it already, in which case you'd no longer need armel or armhf.
As a result, the armel/armhf packages are only useful if your hardware
can't run arm64, at which point you *do* still need a 32-bit kernel,
bootloader, init system, system services, network servers if your
use-case involves those, GUI applications if your use-case is a GUI, and
so on. (And similar for powerpc in -ports.) This is a considerably
larger subset of the distro than what's wanted on i386, so I'm not sure
that it would make sense for inclusion in armhf and inclusion in i386 to
be gated by the same build-profile-or-whatever.
Adrian Bunk's comments elsewhere in this thread, that having the same
package build differently on different architectures can end up being
more work than having it build the same way everywhere, are also
something we should bear in mind - and that's why I'm not sure that the
approach Ubuntu has taken, with more aggressive minimization on i386, is
necessarily the best one either. Perhaps it's a more efficient use of
project members' limited time to keep building everything for every
architecture unless/until a problem is seen, but be then be more willing
to solve that problem via architecture-specific removals that we
historically have been (similar to the removal of mozjs, gjs and GNOME
Shell from armel in the past).
smcv
