[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar

Bernie Innocenti bernie at codewiz.org
Tue Sep 22 02:14:54 EDT 2009

El Mon, 21-09-2009 a las 23:50 -0400, Benjamin M. Schwartz escribió:
> By having distinct packages built separately for each distribution by
> experts.  This is incompatible with our (or at least my) goal of allowing
> users to throw packages around as atomic objects, without internet access
> and without having to understand anything beyond "my friend has Sugar, so
> it will work".  It is also incompatible with allowing novices to generate
> first-class Activities.

I withdraw my previous example.

Admittedly, we couldn't rely on upstream for packaging up things even if
we're using native packaging tools.

> This is also incompatible with your proposal to "choose RPM".  The
> equivalent here would be to choose RPM on Fedora, DEB on Ubuntu, ebuild on
> Gentoo, tarball on Slackware, etc.

Yes, this is what I said initially: use native packages.  RPM was just
an example.

Anyway, we'd have to provide different binaries for different
architectures, distros, and even different distro versions.

The temptation to simplify the universe and declare that there's just
one CPU and just one OS is very strong.  OLPC tried to take exactly this
shortcut, but even in this idealized scenario it will break in many
ways, given enough time: switching to ARM, upgrading to Fedora 42
defaulting to Python 3.0...

> >> I agree, switching bundle formats would gain us a lot of these features.
> >> However, I don't think features such as dependency tracking are of much
> >> use to us, because we can't trust system package managers,
> > 
> > Why not?
> Because there is no way to build a single binary that will safely link
> with all the different distros' libraries

Yes, we obviously need a multitude of binaries built for several distros
and architectures.  I thought this was implicit.

Either this, or we decide that the XO-1 with Fedora 11 is the only
platform that will ever be fully supported by Sugar.  Can we afford to
do that?  Not really...

> > Why would we have to?  Several good distros already exist... just pick
> > one.  No, actually, let's pick many!
> We can't pick one, because we wish to run on them all.  We can't pick
> many, because then users cannot share Activity bundles.

Hmmm, quite an unsolvable dilemma.  Well, maybe not.  We could make a
few compromises that are actually quite acceptable in practice:

 * all "noarch" packages would be interchangeable between 
   different CPUs

 * if two laptops happen to have the same architecture (highly likely
   within one school), they could exchange also the arch dependent

 * Even rpm could be made to work on non-rpm distributions, too.
   See http://kitenet.net/~joey/code/alien/ .  This is a bit of
   a hack, but still more robust than the XO bundles.

 * Direct exchange of bundles between nearby laptops could be seen
   as an optimization.  If the package is not of the right kind,
   the other laptop would fall back to the online repositories

Last, but certainly not least,

 * Activity sharing is not even implemented, yet!  We'll think
   about these esoteric scenarios when they come... if at all.
   The "what if" engineering often results in really bad

   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

More information about the IAEP mailing list