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

[Erik Garrison]

On Fri, Jun 27, 2008 at 05:21:49PM -0400, Michael Stone wrote:
> 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:
> 

Let's say we dist-upgrade our system.  It's in an unbootable state.
In our current situation we attempt to avoid:

>  * can leave the system in an inconsistent or even unbootable
>    state on failure.
>   

... by holding around the most recent distribution snapshot.  A feature
is provided to select that older snapshot at boot time.  Correct?  I've
done it several times in the month+ since I've been at OLPC.

>  * ask users questions during the update process.
> 

This is obviously problematic for our users.  But, I would be extremely
surprised if there weren't ways to specify defaults to use for these
questions and also force the defaults to be used without querying the
user.

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

This is a deficiency of package managers which, if solved by us and
pushed upstream, would be useful to all users of said package managers,
not just OLPC XO's.  That would be a feather in our cap.  We could
probably find assistance in the shape of authors and maintainers of said
package managers.

>  * 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.)
> 

This check, frankly, has nothing at all to do with software
distribution.  We might as well periodically run a script to check for
filesystem corruption.  We could easily trigger it after dist-upgrades.

>  * 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.
> 

As I mentioned above, I thought we already had that button in the form
of the 'swap boot to older version' button.

If this functionality is desired more generally, again, why don't we
attempt to push it upstream so that all users of whatever software
distribution system we use can utilize it?


> 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?"
> 

The technically adept users which you're referring to are:

  (certainly)
  Developers
  Testers
  Deployment staff

  (in smaller proportion)
  Teachers (who want to install specific non-OLPC software)
  Students and end users ..


> 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?
> 

I'm confused by what you mean.

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

What is meant by 'other'?  Where are the showstoppers that imply it
would be impossible to use yum/apt?

The only way to properly integrate the package management system is to
start using it and test it internally.  Where we find problems let's
find the developers of the package manager (for now we're talking about
yum), and ask if fixes are possible.  I have serious doubts that there
isn't upstream interest in meeting our needs as far as package managers
go.  We are currently, and will probably be for some time, the largest
deployment of fedora in the world.  Upstream will listen, and if it
doesn't we can change what we mean by 'up'.

Erik