#6470 NORM Never A: olpc-update doesn't let users manage their software builds

[Zarro Boogs per Child]

#6470: olpc-update doesn't let users manage their software builds
--------------------+-------------------------------------------------------
 Reporter:  gnu     |       Owner:  jg                               
     Type:  defect  |      Status:  new                              
 Priority:  normal  |   Milestone:  Never Assigned                   
Component:  distro  |     Version:  Development build as of this date
 Keywords:          |    Verified:  0                                
 Blocking:          |   Blockedby:                                   
--------------------+-------------------------------------------------------
 (Running update.1-rc1 and rc2 on MP G1G1.)

 olpc-update appears to keep a cache of two software builds, and when it is
 run, it destroys the build which isn't running, and then installs a new
 build.

 And there is some way that the system mysteriously picks which build is
 "default" and which is "backup".

 None of these actions are under the user's control, and they are barely
 visible to the user.

 For example, if I've installed a beta release (such as candidate-691), and
 I don't like it and want to go back to ship.2-656, I apparently have to
 hit the "O" key every time I boot, from now into eternity.  And whatever
 build was my previous backup build is gone, poof!

 For example, if I'm running an update.1 candidate and I want to
 add a second update.1 candidate, I can't do that without destroying
 my stable build.  There's no reason why the file system can't hold three
 releases (especially if two are very close in contents to each other), but
 olpc-update won't let me select such an option.

 olpc-update is constantly described as "not destroying anything" because
 you can get back to the build you were formerly running, with the "O" key
 trick.  But in fact it destroys whatever release you WEREN'T running, and
 does so without warning and without recourse.  This is even true in
 "automated" or "forced" upgrades, which are done by remote control from
 Cambridge without user notice or intervention.

 Instead:

 Olpc-update should always *add* a build to NAND unless it was explicitly
 instructed to delete one.

 It should provide a way to set the default build, to any build it
 currently has.

 It should provide a way to list the current builds (and which one is
 currently running).

 It should provide a way to delete builds from NAND.

-- 
Ticket URL: <http://dev.laptop.org/ticket/6470>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system