On Mon, Jul 6, 2009 at 11:31, Peter Robinson<pbrobin...@gmail.com> wrote: > On Mon, Jul 6, 2009 at 10:13 AM, Tomeu Vizoso<to...@sugarlabs.org> wrote: >> On Mon, Jul 6, 2009 at 11:03, Peter Robinson<pbrobin...@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.
Agreed, I think it was Aleksey who converted some activities to contain binary blobs for several architectures and choosing the right one at runtime. >> 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. Hmm, true. It would need to check that it deletes only the versions it installed. >> 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. Yeah, I like that one as well, I guess a script could make it quite easy to update. Regards, Tomeu > Peter > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
