OLPC-Update + RPMs

[Mikus Grinbergs]

Erik wrote:
> We should move away from using olpc-update to upgrade systems.

Am having a hard time understanding the problem Erik is addressing. 
I do *not* consider the effort that has gone into olpc-update to be 
"wasted" effort.

I think decent 'one-click-installs' are wonderful when they work, 
but leave the user stranded when they don't.  [It's hard to 
anticipate *everything* that might go wrong, and provide "automatic" 
recovery.]  For an OLPC upgrade, I think there will always need to 
be a person to make sure everything worked (a person who can follow 
"cookbook" instructions).


Let's look at how many users need that specific upgrade.
[All these methods are suggestions - any of them might be used in 
any particular situation.]:

  *  If it's one user, then I believe the "mechanism" best suited to
     do the upgrade is determined by  where  the fix is available:
     -  If it is a "whole-OLPC" upgrade, skip down to '100 users'.
     -  If the fix is in a koji-type repository, use a package
        manager (e.g., yum) to install that fix.
     -  If the fix is a file, fetch (e.g., wget) that file, then use
        the appropriate tool to install it (e.g., 'rpm' for system
        stuff, or 'sugar-install-bundle' for application stuff.

  *  If it's more than a dozen users (e.g., one school), then I
     believe a "mechanism" like 'customization' key should be used.
     It would be an administrator/technician who prepares the
     portable device with the fix.

     If it does not exist already, OLPC development needs to create
     the script which performs the actual upgrade from the files on
     the portable device.  [Provision needs to be made for upgrading
     both system stuff and application stuff.]

  *  If it's more than 100 users (e.g., one country), a "whole-OLPC"
     reload might be easiest to manage (using e.g., 'olpc-update'
     to affect system stuff only, or a 'customization' key to affect
     application stuff only; else the whole OLPC could be wiped with
     Secure Upgrade, or even with the 'customization' method.  The
     "country release team" would probably be the ones to prepare
     the media from which such a "whole-OLPC" upgrade is distributed.


With all of these methods, a form of 'dependency hell' may arise. 
If only some modules are replaced, they might not work with whatever 
that user has done to the rest of his system.  If all the system 
modules are replaced, whatever system customizations that user had 
already applied may have to be re-applied;  also, some applications 
the user had already installed may not work with the new system.


--------

Erik makes the suggestion that a package manager ought to be used to 
implement software update procedures (e.g., as in 'dist-upgrade').

The difficulty that I see is that the __packages__ made available to 
that package manager will have to include 'rules' to address the 
'dependency hell'.  Currently, modules at a certain level are 
gathered together into a build;  if that build is to be "official", 
the working together of its modules is tested extensively.  Package 
managers handle individual packages - each would have to indicate 
which other modules/versions it would conflict with.  Lots of work.

> What functionality do we certainly lose by using a package management
> system as our default software distribution system?

The "country release team" loses some degree of control.  With an 
"official" build installed monolithically, there is some degree of 
assurance (to the end OLPC user, and to whoever paid for that OLPC) 
that it will "just work".  When package management as the 
distribution method, who knows whether any OLPC user might 
accidentally end up with an oddball mix of installed modules.


mikus