[Sugar-devel] The ARM is near
tomeu at sugarlabs.org
Fri Aug 28 06:09:57 EDT 2009
On Fri, Aug 28, 2009 at 12:04, Peter Robinson<pbrobinson at gmail.com> wrote:
>>> Bobby Powers wrote:
>>>> I think having something like:
>>>> could work. Sugar could set an environmental variable ARCH to the
>>>> relevant value, and we could have a reference activity_startup.sh
>>>> which adds the correct lib path to LD_LIBRARY_PATH and launches the
>>>> appropriate executable (or maybe a flag in activty.info which has
>>>> sugar do this). This is still somewhat kludgy, but I'm not sure of a
>>>> better way.
>>> Which solution we should choose is a technical discussion that deserves
>>> its own thread. I'm personally not enthusiastic about the "fat packages"
>>> approach, in which binaries for many architectures are included in one .xo
>>> bundle, because:
>>> 1. It wastes space, by carrying around duplicate copies. This gets even
>>> worse for >2 architectures, and even 32-bit and 64-bit x86 might need to
>>> be treated as separate architectures.
>>> 2. It's not future-proof. Packages that work on ARM and x86 will be
>>> broken again if we try to support MIPS (like the Lemote laptops, Free and
>>> perfect for Sugar), or maybe even Sparc or Power (massively SMT chips,
>>> perfect for LTSP).
>>> 3. It won't happen. Cross-compiling libraries is tremendously difficult,
>>> so Activity developers won't do it. They'll just get it working on their
>>> platform and ship it.
>>> 4. It's unreliable. There is no good way to produce binaries that are
>>> guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10.
>>> Changes between versions can break binary compatibility. Between
>>> different distros it's even worse. The Pippy activity recently
>>> experienced exactly this problem due to the included Box2D binary library.
>> I don't think we should aim for the perfect solution here, rather for
>> what can work best for our restricted use cases. Otherwise we run the
>> risk of not moving forward because we take a much bigger challenge we
>> can actually overcome.
>> If fat binaries are not desired, which alternatives do we have?
> There's quite a decent fedora arm secondary architecture 
> community building up. They have a koji instance and instructions on
> how to run a arm VM in qemu . RPM packages can deal with arm vs
> i386 vs PPC or what ever. It would be easy enough to setup various
> repos and koji build instances for building native packages for each
> architecture so as not to have to ship multiple binaries in each
> package and then integration of PackageKit in sugar would solve the
> issues of installation. I don't see why the wheel needs to be
> reinvented when there's a perfectly good working solution for this
One of the problems is that we want our users to write and share code
without having to package it in rpm and/or submitting to koji :/
As a developer, dropping .xo support would take a lot of work from my
shoulders, but I suspect our users would kill us...
>  https://fedoraproject.org/wiki/Architectures/ARM
>  https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
More information about the Sugar-devel