[Sugar-devel] [Marketing] [SoaS] The next Step: v2 Roadmap

[Peter Robinson]

On Mon, Jul 6, 2009 at 10:13 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> On Mon, Jul 6, 2009 at 11:03, Peter Robinson<pbrobinson at gmail.com> wrote:
>>>>> Hi everybody,
>>>>>
>>>>> so here it is, the Sugar on a Stick v2 Roadmap:
>>>>>
>>>>> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Roadmap
>>>>>
>>>>> Feedback is appreciated, and as we've just entered brainstorming phase,
>>>>> please go ahead and shoot your ideas! :) More to come...
>>>>
>>>> For F12 (not beyond), what is the advantage of using RPMs to
>>>> distribute Fructose[1], given OLPC is not[2]?
>>>
>>> +1 to stop distributing activities as RPMs.
>>>
>>> Though we may need a RPM that when being installed downloads and
>>> installs some .xo files.
>>
>> That sounds like a horrible hack to me. The whole point of RPMS is
>> that you can see before you install them exactly what your getting and
>> when you remove them you know that everything goes with them, I don't
>> know how its going to be possible to properly clean up something like
>> that on removal. I think there has to be a use of one or the other, or
>> a combination of the two where core activities are packaged as rpms,
>> or Activities that include binary bits that need to be compiled so
>> that its easy to support on various platforms.
>
> Yeah, I'm not 100% happy on that, but this seems to be a situation
> where the least evil needs to be found.

:-)

> The binary bits issue needs to be solved anyway on .xos (some of them
> are already multi-architecture), so only the scenario of an user
> trying out Sugar on fedora remains.

The issue there is that Fedora could be x86 or ppc, 32 or 64 bit
excluding some of the other secondary arches. Probably not too much of
an issue at the moment but with cheap arm based netbooks starting to
hit the market it could be something that needs to be addressed sooner
or later.

> About cleanup, .xos are expected to be self-contained so when packaged
> as .rpm shouldn't need any cleanup.

If they're proper rpms it should be fine but if there's a single rpm
that pulls .xos from somewhere I don't see how it can know how to
clean up given that after its installed there's nothing to say they
can't be updated manually or through the control panel.

> If people want to package and maintain those as .rpms, I don't see any
> problem with that. But if we don't have enough hands for that, the
> alternative I proposed might be worth it (is actually what SoaS does
> when creating an image).

I think its worth packaging the core activities as rpms such as
read/write/record/speak etc to allow easy testing upstream to make it
easy for testing regressions like we discussed at Fudcon. For the rest
of the activities it might be worth looking at something like an
activity bundle rpm or something similar.

Peter