OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity

[Michael Stone]

On Fri, Jun 27, 2008 at 02:50:34PM -0400, Erik Garrison wrote:
> Existing package managers (e.g. apt, rpm) do exactly what we want and
> more.  Furthermore they are extensively tested and well documented.  Why
> have we locally manufactured and promoted the square wheels of
> olpc-update and copy-nand?

We chose a monolithic update solution because of several deficiencies,
*for our primary use case*, of all package-based upgrade solutions with
which we were familiar at the time. Package-based update solutions with
which we were familiar:

 * can leave the system in an inconsistent or even unbootable
   state on failure.
  
 * ask users questions during the update process.

 * are not adequately bandwidth efficient. (They make no use of
   bitpatterns which are already available on the target system.)

 * do not adequately verify the integrity of the resulting filesystem.
   (We have actually detected two filesystem data corruption bugs as a
   result of carefully auditing our filesystem consistency via the
   update process.)

 * do not innately offer the user a 'big undo' button that permits the
   user to try out large changes with confidence that they can easily
   return to previous system states.

These were some of the considerations that led to the development of the
olpc-update technology.

Now, clearly, there are several technically adept users who would like
to be able to use their favorite package management tools to consume our
software. We _are_ interested in supporting this use case, for example
by modifying our build procedures to produce package repos 'suitable for
use in upgrade procedures'. The hard question is: "what more can we do?"

Do you have other thoughts on either:

  1) other ways that we could address the aforementioned inadequacies of
     package-based updaters for our use case?

  2) other things we can do to integrate package-based updaters into our
     current system?

Regards,

Michael