[Sugar-devel] The ARM is near

[Tomeu Vizoso]

[readding sugar-devel]

On Fri, Aug 28, 2009 at 12:04, Peter Robinson<pbrobinson at gmail.com> wrote:
>>> Bobby Powers wrote:
>>>> I think having something like:
>>>>
>>>> example.activity
>>>> |-arch/
>>>> |-arch/x86/
>>>> |-arch/x86/bin/
>>>> |-arch/x86/lib/
>>>> |-arch/armel/
>>>> ...
>>>>
>>>> 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 [1]
> community building up. They have a koji instance and instructions on
> how to run a arm VM in qemu [2]. 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
> already.

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...

Regards,

Tomeu

> Peter
>
> [1] https://fedoraproject.org/wiki/Architectures/ARM
> [2] 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
Farning