joyride 2128 smoketest

[Eben Eliason]

On Thu, Jul 10, 2008 at 2:15 AM, Erik Garrison <erik at laptop.org> wrote:

> Commonly utilized solution (at least in the Linux world):
>  Use a package manager to manage such details for the user.  For each
> packaged version of an activity, record which versions of other system
> libraries and applications it requires and where to download it.  When
> the user attempts to install a package, check that its dependencies are
> met in the existing system.  If they are not, ask the user if they wish
> to make the required upgrades and inform them of the consequences (in
> terms of memory usage and other software breakage).
>
> Such a system could also be used to deliver security updates and manage
> incremental system upgrades.  (For all discussion of security I've seen
> on the devel list, the distribution of security-related software updates
> is not something I have noticed.  How are we planning on doing this
> outside of olpc-update?)

I'm personally less concerned with the particulars of security
updates, but would say only that I'd prefer them to be pushed to the
machines automatically if desired, or at least made a one-click update
otherwise, ideally with some form of notification that an update is
available.  For that matter, olpc-update should ultimately be replaced
by a similar push/notification scheme, with a simple button press
(likely in the "about this XO" section of the control panel) to
update.  We could even extend this section when a dev key is detected,
to make installing "cutting edge" builds simple as well.  We might
also want to provide a link to the release notes in the same place.

> The problem of software deployment which you note in #3 is _exactly_ the
> kind of problem that package management system could be used to solve.
> We already ship one on the laptop (yum)!  Perhaps we could be using it
> to handle our activity updates?  If the problem is that yum is slow and
> awful, then maybe we need to start thinking about using apt.
>
> In the long run I have trouble imagining how this problem will be solved
> without roughly approximating the behavior of apt or rpm package
> management systems.  I suggest we start exploring methods to install and
> upgrade activities using such systems.  I do not know if this is
> something we can manage for the 8.2 release, but I would be more than
> willing to start working on it as soon as necessary.

So, there are two reasons that I'm /really/ hesitant to jump into the
average packaging model.

1. Activity bundles, to the extent possible, are designed to be as
self-contained as possible.  This is a trade-off, as obviously
required components that aren't on the system take up extra space in
the bundle, and may even be duplicated.  Early on we decided this was
an acceptable cost to support non- or intermittently-connected
circumstances, and to make possible ubiquitous peer to peer
bundle-sharing over the network.

2. We highly dislike the idea of presenting kids with "installation
procedures" of any kind.  For that matter, it's almost a shame that we
even have to do the technical step of unzipping the bundles to
officially install them, unlike, for instance, .app bundles on OSX
which run from anywhere, and are "installed" inasmuch as they reside
/somewhere/ (even external devices).  I'd really like to see us find a
way to make our bundles run "in place", so that kids can run large or
infrequently used activities off of USB sticks, for instance.  But,
back to the point, the only thing a kid should have to decide when
"installing" an activity is that they actually want to do so.


It seems that the only dependency info that does make sense is which
packages are required in the core build (can we somehow wrap API
versions into this equation as well?) for it to run.  That is, either
everything that this activity expects to have in Sugar itself is
present, or it's not, and we can then make basic recommendations on
what activities are compatible with what releases of Sugar based on
that.

- Eben