Ticket #4951 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

activity update.

Reported by: cscott Owned by: cscott
Priority: normal Milestone: 8.2.0 (was Update.2)
Component: distro Version:
Keywords: Cc: mstone, cjb, krstic
Action Needed: test in build Verified: no
Deployments affected: Blocked By: #7494, #7495
Blocking: #6523, #7396

Description

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.

Change History

  Changed 7 years ago by cscott

  • cc mstone, cjb, krstic added

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.

  Changed 7 years ago by krstic

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

  Changed 7 years ago by 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.

  Changed 7 years ago by 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.

  Changed 7 years ago by 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.

follow-up: ↓ 7   Changed 7 years ago by 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.

in reply to: ↑ 6 ; follow-up: ↓ 9   Changed 7 years ago by krstic

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

follow-up: ↓ 10   Changed 7 years ago by 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

in reply to: ↑ 7   Changed 7 years ago by 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.

in reply to: ↑ 8 ; follow-up: ↓ 11   Changed 7 years ago by 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.

in reply to: ↑ 10   Changed 7 years ago by 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.

  Changed 6 years ago by 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

  Changed 6 years ago by cscott

  • blocking 6766 added

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

  Changed 6 years ago by cscott

  • blocking 6792 added

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

  Changed 6 years ago by cscott

  • blocking 6523 added

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

  Changed 6 years ago by cscott

  • blocking 7396 added

  Changed 6 years ago by cscott

  • next_action set to never set

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.

  Changed 6 years ago by mstone

  • next_action changed from never set to test in build

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

  Changed 6 years ago by cscott

In what form?

  Changed 6 years ago by cscott

  • blockedby 7495 added

  Changed 6 years ago by 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.

  Changed 6 years ago by 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.

  Changed 6 years ago by cscott

  • blockedby 7494 added

  Changed 6 years ago by cscott

  • blocking 6766 removed

  Changed 6 years ago by cscott

  • blocking 6792 removed

  Changed 6 years ago by martin.langhoff

  Changed 6 years ago by cscott

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.