[Sugar-devel] Oversight Board request: Not fully bundled .xo
alsroot at member.fsf.org
Thu Mar 4 15:54:21 EST 2010
This is request to Oversight Board because of:
* Activity bundles (.xo files) are one of sugar cornerstones
positive answer to this question will affect general sugar workflows
(see background notes for examples).
* Sugar upstream (Sugar Labs) should be more friendly to existed, not
sugar based, education software to provide sugar killing features for
these projects instead of reimplementing education stack in sugar.
And activity bundles are obvious tools for that but existed .xo
format does not work well here.
* The main Sugar Labs (thus downstream agnostic) deployment instrument -
Activity Library  is getting to be messy when more than a half of
activities are binaries, it is a real problem since SL is not
GNU/Linux distribution vendor and more over should be distribution
agnostic and .xo are not intended to handle binaries properly.
* The matter of this request is not technical details (will be discussed
in more regular ways) but declaring principal changing in sugar
* Things like poll is not so popular  and it is pretty unfair to make
critical decisions basing on 14 votes.
Can activity bundles on Activity Library  be not fully bundled
and demand additional (except having .xo) steps (that in most cases
will demand network connection) to its launch.
Possible implementation details (is not a part of request, just info):
* Using 0sugar  infrastructure to handle non Sugar Platform 
dependencies. 0sugar is an infrastructure wrapper around 0install .
* Fully bundled .xo could be preserved (it makes sense for pure network
environments), not fully bundled activities could be in form of web
urls for example  in that case they will obviously separated from
* Activity Library  could provide two download buttons, one (main)
for regular fully bundled .xo and second for lightweight activities.
* Binary dependencies (if there is no way to install from native
packaging systems) will be built on public building farm thus we can
guarantee that they will be built properly and will keep activity
developers out of such not trivial stuff.
.xo idea of being fully bundled is pretty useful on its own and works
fine in case of pure python activities.
But I'm sure SL's purposes is not creating python based education
platform thus it is more useful way to treat sugar as an education
environment which provides useful features for the rest of education
software instead of creating education platform from scratch in pure
python. Distribution agnostic deployment portal - ASLO, would be
another killing future of sugar when all education software that
support sugar platform could be installed from one place. From that
point fully bundled .xo don't work because bundling Java or Qt is
Fully bundled .xo could still work in case of one deploying scheme
e.g. OLPC - there is only one hardware platform and only one software
platform with release cycle more then a year (2?). Another successful
example is MacOS which is also only one software platform with long
releasing cycle. But SL's case if different since it is trying to be
GNU/Linux distribution agnostic and fully bundled binaries don't play
here. Thus GNU/Linux distribution efforts should be used as much as
possible when proper dependency will be installed from native packages
and fallback for homemade binaries in extreme cases.
More information about the Sugar-devel