All Activities should live in /home/olpc/Activities

[cscott]

To support separate upgrade of activities and the base OS, all activities should live in /home/olpc/Activities.

Currently "base system" activities live in /usr/share/activities, which "user downloaded" activities live in /home/olpc/Activities. Having multiple locations complicates Activity upgrade: we can have a 'base system' TamTam in /usr/share/activities, and then a slightly newer TamTam in /home/olpc/Activities, and we have to carefully hard-link files between these to avoid having (for example) two copies of the 4M Tam Tam sound library.

[jg]

Please use this as a tracker bug, and file bugs against each individual activity.

[marco]

It should not be necessary to change any activity. This should just be a pilgrim fix afaict.

[marco]

Once this is done in the distro please reassign to sugar/marco. I want to fix it in sugar-jhbuild too.

[J5]

Are we still going to do this or are we going to leave the base activities in /usr/shared?

[cscott]

I think I've been convinced by the 'fallback version of base activities in /usr/shared' design, even though it complicates activity launch (need to determine which location to use) and upgrade (need to share files with base system; base system has independent upgrade mechanism).

Since time pressures are looming, upgrades to the activities in /usr/shared might be the *only* way to upgrade activities in the near term.

[J5]

closing this bug as we will now have default activities in /usr/share and user installed in /home/activities

[cscott]

Hey, I think I won this one (eventually).

[bert]

Nope. The olpc3 build is a regression. It has activities in the base build again. Also, joyride still includes activities.

It is fixed for update.1 though, so I'll request retriaging. Is anybody doing this these days?

[sj]

Replying to bert:

Nope. The olpc3 build is a regression. It has activities in the base build again. Also, joyride still includes activities. It is fixed for update.1 though, so I'll request retriaging. Is anybody doing this these days?

I agree with Scott's original idea of having fallback activities in /usr/share.. This suggests that 'core' activities can be defined as those which we consider worth using space in all builds for. We can support "removing" them by adding a stub activity with the same name in /home/olpc/Activities that is functionless and invisible, and "updating" them by installing a new version into /home/olpc/Activities, at a space hit of at most twice the disk footprint of the original.

These 'core' activities should be ones which

• comply well with our criteria for great activities (see #6598 and the wiki page)
• specifically demonstrate collaboration and what makes Sugar special
• help bootstrap the transparency and hackability of the system (so if 'view source' or 'publish' or 'journal' are implemented as Activities [which I'm not sure they should be, simply for clarity of jargon], they rank highly here)
• are small enough for the advantages to outweigh the extra disk used (extra weight on this criterion; at most double the normal weight :)

Bert and marco, would you disagree with this notion of a core activityset? SJ

[cscott]

Activities are in /home.