activity update.

[cscott]

We should be able to check for new versions of activities, and update them.

When we update them, we should not download files inside the .zip which we already have; we should hardlink to share space instead.

[cscott]

For the record: the shared files mechanism is intended to allow activities to be completely self-contained, eliminating the need for dependencies. Each activity will include all the files it requires (for example, a complete java runtime if the activity is written in Java); if those pieces are not required on the target, they are never downloaded nor installed on disk.

We maintain a list of file hashes installed on the system. The 'contents' file inside the activity bundle allows us to detect which files are already present on the target, and the .zip file format allows us to use http byte range requests to download only the needed files from the .zip.

[krstic]

Some of this is detailed in the original spec (not updated since) at http://wiki.laptop.org/go/XO_updater

[cscott]

We need one additional field in the activity-info file: update_url.

This contains a URL which points to update information; at least the pair of 'activity version' (an integer) and 'activity url' (a url at which we can download that version of the activity).

Michael and I are still discussing whether the format of this update information should be json, or xml, or plain text, or what.

[Eben]

I might vote for XML, as I think the RSS "appcasting" approach is rather nice. It keeps the format simple and clean, and would also make it easy for someone (even us?) to create an aggregator for feeds that developers submit, allowing a central source to automatically detect updates without requiring developers to resubmit.

JSON is an interesting alternative, but I'm not sure when it will ever be useful to interpret the results of such a query with JS.

[krstic]

Scott: what's the reason to _not_ make it JSON, since that's what we've been informally standardizing on?

Eben: Ignore the "JS"; JSON isn't Javascript-only. It's a valid subset of YAML, it can be directly executed by Python, and is at this point parsable by just about anything else.

[cscott]

The reasons (not strong ones) are these:

a) for the time being, activity authors will have to manually create these 'latest version' files, so the closer to plain text, the better. One proposal was creating a wiki template for activity information on wiki.laptop.org; this would suggest pulling information out of pseudo-xml, but...

b) if this is intended as a stop-gap until we've got a proper distributed versioned filesystem that will manage activities, then we don't want to waste effort on a all-singing all-dancing system that will just be soon obsoleted.

[krstic]

Those are fair reasons in favor of considering something even simpler than JSON, e.g. plain text. Certainly not XML :)

[bert]

Proposal: Reuse existing joyride ChangeLog format

- People do not have to edit two places to release new versions. They could simply link their public_rpms/joyride to their public_html/something (or of course make a separate changelog for public updates)

- it includes changelog entries that could be displayed to the users

- we do not habe to invent a new text file format

[cscott]

Replying to krstic:

Those are fair reasons in favor of considering something even simpler than JSON, e.g. plain text. Certainly not XML :)

I favor plain text, but I can't seem to find an easy way to get the wiki to spit it out. Maybe SJ or some other mediawiki wizard can give us a way to pull the 'raw unformatted text' version of a wiki page?

An alternative is using some sort of magic delimiter around a plain text string, so that a simple regexp can pull the info out of the middle of a crufty HTML page.

[cscott]

Replying to bert:

Proposal: Reuse existing joyride ChangeLog format

The existing ChangeLog does not give a URL from which the described version of the package can be downloaded, except implicitly ("the named file, in the same directory you pulled the ChangeLog from"). I'd prefer to allow indirection: I expect third-party developers may wish to use (say) laptop.org's wiki to describe their activity, provide screenshots, and list the latest version while actually hosting their XO bundle elsewhere. Requiring third-party activity authors to have an account on a general webhost seems a high barrier.

[bert]

Replying to cscott:

Replying to bert:

Proposal: Reuse existing joyride ChangeLog format

The existing ChangeLog does not give a URL from which the described version of the package can be downloaded

Well, we could simply allow to give a full URL instead of the partial one listed now.

[cscott]

m_stone suggests automatically launching the activity updater if sugar starts and finds it has no activities.

newsham suggests that the activity updater be automatically launched when you insert a usb key with activities on it.

design details at http://wiki.laptop.org/go/XO_updater#Application_updater

[cscott]

(In #6766) When the activity updater is complete, there will be an activity group similar to what "joyride activities" used to me. I will add Bounce and Colors to that group at that time.

[cscott]

(In #6792) When the activity updater is complete, there will be an activity group similar to what "joyride activities" used to be. I will add Bounce and Colors to that group at that time.

[cscott]

(In #6523) When the activity updater is complete, there will be an activity group similar to what "joyride activities" used to be. I will add this activity to that group at that time.

[cscott]

Just added code to joyride (in the sugar-update-control package, but see also bug #7486, which had to be worked around) to implement a software update control panel for sugar. The code itself (at http://dev.laptop.org/git?p=users/cscott/activity-updater ) is heavily documented; I'll update the appropriate wiki pages with more intelligible explanations of how it all works before I close this bug.

[mstone]

This code can be tested in joyride-2153 and later. Scott - could you please supply some test cases?

[cscott]

In what form?

[cscott]

Here's the actual desired test case:

Start with build 650, 653, or 656. Use olpc-update to upgrade to joyride-2153. On reboot, the sugar control panel should open automatically (trac #7495); if trac #7495 hasn't been fixed yet, right click on the XO man, select 'control panel', then select 'software update'. You should see a list of activities requiring update. Click 'install'. All the activities should install correctly. (That is, after you click 'install' and the installation completes, the control panel should read, 'your system is up to date'.) Close the control panel, look at the activity list view. The set of activities should match those in http://wiki.laptop.org/go/Activities/G1G1 -- that is, the "no activities on upgrade" problem (#7093) should be fixed.

Second test case is starting from 8.1 (703) or 8.1.1 (708) with the 'G1G1' activities installed. All activity updates should install correctly, as before.

[cscott]

I should mention that #7494 currently causes the 'Browse' update not to complete successfully. That's a known bug, but not in my code.

[martin.langhoff]

With Douglas' help added some notes at http://wiki.laptop.org/go/XO_updater#Notes_on_sugar-update-control