Ticket #2064 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

All Activities should live in /home/olpc/Activities

Reported by: cscott Owned by: dgilmore
Priority: blocker Milestone: Not Triaged
Component: distro Version:
Keywords: Cc: cscott, tomeu, jg, walter, dgilmore, kim, mstone, cjb
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

  Changed 7 years ago by jg

  • cc cscott added
  • owner changed from jg to J5
  • priority changed from normal to blocker
  • milestone changed from Untriaged to Trial-3

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

  Changed 7 years ago by marco

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

  Changed 7 years ago by marco

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

  Changed 7 years ago by J5

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

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

  Changed 7 years ago by tomeu

  • cc tomeu added

  Changed 7 years ago by J5

  • status changed from new to closed
  • resolution set to wontfix

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

  Changed 6 years ago by cscott

  • cc jg, walter, dgilmore, kim, mstone, cjb added
  • status changed from closed to reopened
  • resolution deleted
  • milestone changed from Trial-3 to Update.1

  Changed 6 years ago by cscott

  • owner changed from J5 to dgilmore
  • status changed from reopened to new

  Changed 6 years ago by cscott

  • status changed from new to closed
  • resolution set to fixed

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

follow-up: ↓ 12   Changed 6 years ago by bert

  • status changed from closed to reopened
  • resolution deleted
  • milestone changed from Update.1 to Retriage, Please!

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?

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

  Changed 6 years ago by cscott

  • status changed from reopened to closed
  • next_action set to never set
  • resolution set to fixed

Activities are in /home.

Note: See TracTickets for help on using tickets.