[Sugar-devel] The ARM is near

[Tomeu Vizoso]

On Fri, Aug 28, 2009 at 12:23, Peter Robinson<pbrobinson at gmail.com> wrote:
>> 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 :/
>
> Well you might need to do something along the lines of if its pure
> python and hence can run on any platform you can use .xo files. If you
> want to include binaries you have to go the rpm route. If they can
> write and compile C code they should be able to make a rpm. That way
> you keep the simple .xo but have a way of ensuring less issues with
> binary code.
>
>> As a developer, dropping .xo support would take a lot of work from my
>> shoulders, but I suspect our users would kill us...
>
> I suspect users will kill you as well when activities don't work on
> machine X but they do on Y....... your damned if you do, damned if you
> don't. Either way there's going to be pain, whether its the in the
> short or the long term.

Yeah, I guess Jonas' suggestion of promoting platform independent
bundles as "first class" addresses this concern.

I personally don't think we are going to be able to outdo rpms nor
debs so the less binary code we have the better.

That said, our users are free to do whatever they want and Sugar will
be deployed in wildly different scenarios. So I think that leaving
some extra flexibility is wise because if we try to anticipate all the
ways in which Sugar will be used, we'll fail.

And if activity authors want to get together and unify binary blob
handling, that's their business.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning