armhf status
choices:
- drop
- keep
prior discussion:
reasons for keep:
- some (seemingly mostly abandoned?) postmarketos devices. almost all of these use not-up-to-date-kernels now
- slightly dated issue in pmos: https://gitlab.com/postmarketOS/pmaports/-/issues/599
- the rpi0 and rpi0 w
- these are produced until 2026, and are quite popular.
- however, almost no other devices really use this architecture, except...
- these are produced until 2026, and are quite popular.
reasons for drop:
- toolchain support for armv6 only gets increasingly poorer. issues such as https://github.com/llvm/llvm-project/issues/41201 have existed for years without resolution, and that one specifically causes e.g. rust to fail without applying workaround
- of course, one could say this is niche to our setup. it also cost me dozens of hours until clandmeter remembered what the issue was...
- most patches to 'fixing something on armhf' are usually something of a weirder hack and never upstream. i don't have any links, however
- the 'passive costs' of keeping an architecture
- niche failures cause someone to look at them at least once, take up CI time, ..
- a (mostly) full built package set takes mirror space, including every release
- some people find it 'annoying' to do
arch="all !arch"
and try to enable things on every arch even when it does not make sense, and spend both their own time and maintenance time on things like enabling packages that don't have value (graphical apps, ..)- (so by dropping it, the
!arch
is not even needed in that case and nobody thinks about it)
- (so by dropping it, the
currently the status can be summarised as follows:
- armhf is enabled, some stuff like qt5 is disabled on it
- when something doesn't build on armhf, it just gets disabled and everyone moves on. no time spent on it
- this is okay, as practically nothing disabled would be ran on these tiny 512M devices anyway (graphical apps)
continuing to do that is okay. dropping it would also have its maintenance benefits.