Re: building fewer packages or reduced functionality on i386

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