Re: Summary of the ARM ports BoF at DC15
Steve McIntyre wrote...
> First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood
> & some freedombox. Toolchain and kernel support upstream are probably
> never going away due to the massive number of simple ARM devices still
> being made and shipped, however...
Quite recently I saw an ARMv4 (without thumb, long-gone arm
architecture) hardware on sale. Probably too small for Debian, but
bigger boxes were sold until 2009-ish, and fell out of support rather
soon.
What I'm trying to say: Please keep old arches as long as reasonably
possible. There's still a surprising amount of people who use it. So
in my opinion it is *way* too early to consider ending armel support.
(But this is not a plea to restore arm, with oabi support dropped in
gcc it's really dead now. Although it still shows up on popcon.)
> Should we keep it for Stretch? Maybe with subarchitecture support,
> when available. We still have some users, but not *many*. tbm would
> miss it and is still supporting quite a lot of users. Could we get the
> people who care about armel to do a minimally-supported LTS for
> Jessie/Stretch? Typical users are now on NAS boxes or some
> Freedomboxes, just using server software - no X, no graphics etc.
> Should be possible?
It's sound to assume virtually nobody runs big packages like iceweasel
or libreoffice on armel boxes. My problem with a subset is rather why
you would want to do this at all. Is there any reason beside buildd
utilization? Since the whole idea raises a lot of questions: Where to
draw the line, and how to assert no breakage is introduced in build
dependencies.
As an example, if the armel box is a router, the admin might want to
install mtr-tiny to debug some kind of network problems. The mtr
source package also builds a GUI version "mtr", so either you'd still
have to support libgtk2.0-dev, and subsequently the X core - or you'd
have to split the build scripts for different use cases. Something
similar had been done before for stage builds, which is quite a pain
to understand and to maintain.
Long story short: You might drop a few leaf packages but anything
beyond this creates a lot of continuous work I doubt many people are
willing to do.
> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.
So add me to your list. I run four Seagate DockStar (v5) and two
Raspberry Pi (v6, first generation). Although bout the latter, I was
hoping for a "arm6hf" port and used armel until then. But with more
recent Pi models AFAIK being armhf compliant, this will not happen
anymore. Combined with the really poor performance I should rather
wait for the right moment to brush them under some carpet.
Also, flash size for the kernel image is not a problem: These boxes
boot from external mmc or usb.
Christoph
Reply to: