Yes, embedded systems do need multi-arch!

Paul Whittaker <[email protected]>
Newsgroups gmane.linux.debian.devel.embedded
Message-ID <[email protected]>
As an Emdebian newcomer (but long-time embedded Linux afficionado) who 
is looking at Emdebian to form the basis of a commercial embedded thin 
client O/S for my employer, ThinLinx Inc (thinlinx.com), I was annoyed 
to discover that Emdebian Grip (stable, at least - I see from your FAQ 
that jessie-grip may be a different story, but that doesn't help me 
right now) lacks Multi-Arch headers in its package metadata, thereby 
rendering multi-arch effectively unusable even though the package 
contents themselves are multi-arch-ready.

The Emdebian FAQ states that "it [was] not expected that many devices 
running Emdebian Grip would need to use Multi-Arch", a decision which I 
assume was based on reasoning along the lines of "multi-arch is only for 
development, so you don't need it on a production system, right?".  If 
that was your thinking, I am here to assure you that, from a commercial 
embedded Linux standpoint, you were wrong.

We do need multi-arch at runtime.  We need it because not all code that 
we use is open source, or even available to us in source form. Some 
industry partners and/or upstream software suppliers are slow to adopt 
newer ABIs.  Case in point is Citrix Receiver, formerly Citrix ICA 
Client.  It's currently only available for ARMEL, and we would really 
prefer to use ARMHF.  It's not so very long since ICA Client was only 
available for Standard ABI, and they didn't have an EABI build!  Another 
example from the x86 world, that many of you may recall, was the Adobe 
Flash Player browser plugin - Adobe failed to produce a 64-bit port of 
their 32-bit plugin for many years after fully 64-bit Linux systems 
became popular.

I am persisting with Emdebian Grip, because I think that it offers 
enormous flexibility at a relatively affordable resource cost, but for 
now I'm going to have to maintain parallel ARMEL and ARMHF builds 
(either that, or extract ARMEL packages outside of package management on 
my ARMHF build, which I am loath to do).

But please, next time you make a decision like this, consult the broader 
community first, at least if you entertain hope of attracting serious 
interest from industry!

P.S. For others hoping for an ARMHF Citrix Receiver, we have nagged them 
about this, and they have assured us that they are working on it!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.