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

[Aleksey Lim]

On Thu, Mar 04, 2010 at 05:47:17PM -0500, Benjamin M. Schwartz wrote:
> Aleksey Lim wrote:
> > what ASLO is,
> > in my mind it was deployment agnostic thus if we have packages for 0.84 on
> > bunch of distros, ASLO activities that are stated 0.84 ready should just
> > run.
> 
> I agree.  OLPC needs this as badly as anyone.
> 
> OLPC already supports users on a mix of Fedora 9- and Fedora 11-based
> systems.  For all I know there might still be a few running Fedora 7 and
> Sugar <0.82.  The situation is only likely to get more mixed in the
> future, and OLPC appears to be moving seriously toward ARM-based laptops,
> so even individual OLPC schools will be running a mixture of different CPU
> architectures.
> 
> >> As for the rest... I think .xo bundles should be absolutely free of binary
> >> executables, or anything else that depends on more than the Sugar
> >> Platform.  We should then introduce a different (better!) bundle format
> >> that supports such dependencies, based on 0bundle, 0install, etc.  As a
> >> temporary codename, call it ".x0".
> > 
> > well, and it was the main purpose of SLOBs request, to know how sugar
> > should move forward. And once more it is not my idle curiosity, in my
> > mind ASLO turns to be a garbage heap of blobs when there is no chance to
> > know will particular blob run in particular environment or not
> 
> I don't think SLOB can help much here.  I think we are already approaching
> consensus.  Part of that consensus is: we can't afford to "just drop" all
> the "incomplete .xo's" that require external dependencies or include
> non-portable executables.  Before we can clean up the current mess, we
> need a solid, supported solution for those Activities.

agree as well, my thought about requesting SLOBs is that there is a fork:

    * only SP activities
    * activities w/ non SP dependencies

and would be very useful (for everyone) if we explicitly follow one
particular thread.

> 
> --Ben
> 



-- 
Aleksey