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

[Gonzalo Odiard]

I think the .xo activities must be noarch only. These can be modified by
teachers and kids, shared, you can "view-source" etc.
The .xo can require the binary dependencies using PackageKit.
Now we have one hundred activities based in GCompris and avery one must add
the binaries and the activities like Phisics include the binaries for every
plataform.
Please don't reinvent the wheel.

Gonzalo


On Tue, Sep 22, 2009 at 3:14 AM, Bernie Innocenti <bernie at codewiz.org>wrote:

> 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
>   packages
>
>  * Even rpm could be made to work on non-rpm distributions, too.
>   See http://kitenet.net/~joey/code/alien/<http://kitenet.net/%7Ejoey/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
>   engineering.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Gonzalo Odiard
Responsable de Desarrollo
Sistemas Australes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090922/677f45a4/attachment.htm