[Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo

[Aleksey Lim]

On Thu, Mar 04, 2010 at 04:11:30PM -0500, Chris Ball wrote:
> Hi Aleksey,
> 
>    > Can activity bundles on Activity Library [1] be not fully bundled
>    > and demand additional (except having .xo) steps (that in most
>    > cases will demand network connection) to its launch.
> 
> Sounds like this should be a

> Development Team

but it is mostly not Deployment Team case (afaik Development Team means
core team) since requested changing affects general workflow.

> Deployment Team

* would be good to hear any feedback but I guess there weren't many of them

* the major issue here that ASLO is not particalr deployment oriented
  portal, e.g. in OLPC case, mentioned issue is mostly means nothing
  since OLPC can effectively add/remove any component they think is
  useful for their users, in contrast, ASLO (afaik) is deployment
  agnostic

> decision, unless you've already tried hard and failed to reach
> agreement there.  (Do you think that's the case?)
> 
> Speaking as part of that Devel Team discussion (and not as a SLOB),
> the current setup of not knowing beforehand whether a .xo bundle is a
> complete activity or a partial activity is really hard to deal with.

yup, proposed [1] could minimize disadvantages (of course it is not
idela) with preserving fully bundled .xo and "links" to activities when
users obviously know that it is a link and they (implicitly) need to
download it

> I think the current situation is very frustrating for anyone who is
> downloading activities on a separate machine to the one they run them
> from, such as XO users who depend on other people to download and
> bring them activities with sneakernet.

yup, it is an issue (but shouldn't be on current ASLO)
but ASLO could provide (as a main download link) regular fully bundled
.xo.

The reason to have second downloading link on ASLO for "lightweight"
activities is proper handling situation when there are several Java based
activity and several version of each activity and user who has proper
java installation. OLPC can add java to XO distro, not sugar if java
could be added to Sugar Platform (because it should mean that *every*
sugar box should have java) thus every .xo on ASLO will weight +50M (or
after adding ARM, +75M), pretty useless if activity itself weights 5M.

Another reason against bundling blobs is that we are trying to do pretty
ugly thing to pass around GNU/Linux distributions efforts in over words 
ASLO uploader who bundles blobs will try guess what targeted environment
would be.

Keeping all these in mind, we can either stop bundling blobs(and say
"Please do not upload java(e.g.) based activities to ASLO") or use
something more reasonable then .xo. Both cases are better then current
one when there is not any policy.
 
> I think that these partial activities should not be used

s/used/uploaded-to-ASLO/ I guess :)

and it is also a way which is better then current, we just need to make it
clear for other education projects that if they want to add sugar
support to their projects, they need to request for inclusion theirs
dependencies to Sugar Platform (but we can't add all debian repo to
sugar dependencies, thus have to say "no" for some projects).

> until we've
> found a way to make their dependencies

> (a) obvious to people who are
> downloading the activity from ASLO

not sure if I got it, dependencies could be bunch of .so like libxmls,
libcairo etc.

>, and (b) easily downloadable at
> the time as the activity, to enable sneakernet downloading.

and it could be done by in new scheme

> 
> Thanks!
> 
> - Chris.
> -- 
> Chris Ball   <cjb at laptop.org>
> One Laptop Per Child
> 

[1] http://wiki.sugarlabs.org/go/Features/Zero_Sugar_Activities#Detailed_Description

-- 
Aleksey