Opened 7 years ago

Closed 6 years ago

#2064 closed defect (fixed)

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
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no

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 (13)

comment:1 Changed 7 years ago by jg

  • Cc cscott added
  • Milestone changed from Untriaged to Trial-3
  • Owner changed from jg to J5
  • Priority changed from normal to blocker

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

comment:2 Changed 7 years ago by marco

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

comment:3 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.

comment:4 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?

comment:5 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.

comment:6 Changed 7 years ago by tomeu

  • Cc tomeu added

comment:7 Changed 7 years ago by J5

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:8 Changed 7 years ago by cscott

  • Cc jg walter dgilmore kim mstone cjb added
  • Milestone changed from Trial-3 to Update.1
  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:9 Changed 7 years ago by cscott

  • Owner changed from J5 to dgilmore
  • Status changed from reopened to new

comment:10 Changed 6 years ago by cscott

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:11 follow-up: Changed 6 years ago by bert

  • Milestone changed from Update.1 to Retriage, Please!
  • Resolution fixed deleted
  • Status changed from closed to reopened

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?

comment:12 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

comment:13 Changed 6 years ago by cscott

  • Action Needed set to never set
  • Resolution set to fixed
  • Status changed from reopened to closed

Activities are in /home.

Note: See TracTickets for help on using tickets.