[Bugs] #105 NORM: SoaS should include the software update control panel

[SugarLabs Bugs]

#105: SoaS should include the software update control panel
----------------------------------+-----------------------------------------
    Reporter:  cjb                |          Owner:  bernie                     
        Type:  defect             |         Status:  assigned                   
    Priority:  Normal             |      Milestone:  Unspecified by Release Team
   Component:  SoaS               |        Version:  Git as of bugdate          
    Severity:  Major              |     Resolution:                             
    Keywords:  community-request  |   Distribution:  SoaS                       
Status_field:  New                |  
----------------------------------+-----------------------------------------

Comment(by garycmartin):

 Coming in from the sidelines here, but my understanding is that sugar-
 update-control was only ever intended as mechanism for keeping already
 installed Activities easily up-to date. It then gained (a point of some
 contention) the ability to install a whole collection/pack of Activities
 like the G1G1 or Peru set. This seems to have been an attempt to solve 1).
 the issue caused when all Activities were dropped from the base Sugar
 install image and everyone was swamped with "I have an empty home view
 with no Activities, how do I get them back?" support calls; 2), and the
 versioning rabbit-hole for specific deployments who could have different
 Activity version requirements and OS builds, relative to the official
 releases.

 I don't know what's been done so far other than to try and make the sugar-
 update-control code run in the new Sugar and distro environments/platform;
 but to be useful, the process would need to:

 1). understand the qwerky directory layout and file permission issues
 created by the Soas distro – it needs to know what it can actually upgrade
 and where it lives (needs to be every Activity in my opinion, I can easily
 see needing to download a bug fix version of a core Activity like Browse
 at some point in a Soas release life cycle).
 2). Contact activities.sugarlabs.org for Activity version information and
 downloads.
 3). Extend activities.sugarlabs.org so it generates the microformat xml
 that was designed for the sugar-update-control process

 Regarding the maintaining of Sugar and the underlying distro components in
 the field, I've not seen too much discussion of upgradability or an
 upgrade procedure yet. I assume quite a bit of this low level stuff is
 suited to existing distro procedures (yum/aptitude/...) which could
 potentially be given a separate graphical UI. I guess for a major version
 upgrade, if backup is working well (data-store, all user preferences, and
 likely some other identity/misc items), this could be close to "backup ->
 make fresh Soas -> restore (-> upgrade to latest Activities)."

-- 
Ticket URL: <http://dev.sugarlabs.org/ticket/105#comment:17>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system