Cannot Erase activities installed in /usr/share/sugar/activities

[wadeb]

In SoaS-1 (and probably SoaS-2) the Erase context menu does nothing when used on an activity installed to /usr/share/sugar/activities.

This is likely because these files are owned by root and cannot be deleted by the user.

Recommended solution: Stop using /usr/share/sugar/activities, install everything to /home/liveuser/Activities/.

[garycmartin]

+1

SoaS for a while now has had a nasty real combination of Sugar unfriendly /usr/share/sugar/bundles, /usr/share/sugar/activities, and sym links in ~/Activities, all owned by root. None of which can be managed by users from the Sugar UI (erase or upgrades are just broken). First thing I do with a Soas build is to ditch all these and manually copy them to ~/Activities back to the default user, but real users will just think Sugar is broken and buggy.

[sdz]

I'm really hesitating to close this as 'wontfix', but that's probably just the way it is. I see all these points and... well, have a look at this: ​https://fedoraproject.org/wiki/RPM_vs_XO_FUDConF11_BarCamp_session_20090110

The packages in /usr/share/sugar/... are obviously those being installed as RPMs. Citing from the above source: 'as fructose activities are installed by root every user on a multi-user system (school lab) have a basic system where he can not delete the core activities'

So this is because of the intentions the decisions on FUDCon were made with. (I didn't attend FUDCon, though.) Feel free to reopen this ticket or discuss it here. ;)

[wadeb]

I understand the point, but I feel like the fact that you cannot install *new versions* of core activities overrides this.

I also personally believe we should allow users to remove anything they want to remove. If they remove Browse and Terminal, they can always put .xo files on a USB stick or SD card and re-install them that way.

And schools might prefer to remove things like Terminal in their local keys.

What's the best forum to bring this issue back up in? sugar-devel?

[wadeb]

I'm also really concerned that many non-critical activities are installed this way, and thus can never be removed or upgraded.

Finance, Typing Turtle, Colors!, etc.

Would it be possible to install these via .xo instead of by .rpm?

It should be as simple as replacing the 'rpm -i' commands for activities in the kickstart with 'wget <url> && unzip <xo file>'

[garycmartin]

If we're really going to stick with a sub-set of Activities that no (normal) user can erase or upgrade, we should at leased file a critical blocker against the Sugar component for either an alert message if a user attempts to erase a locked activity, or that the erase palette option is disabled (greyed out) for root locked activities. Not too sure where warnings should go when a user blocked from upgrading a root locked Activity. What do others think?

[sdz]

Replying to wadeb:

I'm also really concerned that many non-critical activities are installed this way, and thus can never be removed or upgraded.

Finance, Typing Turtle, Colors!, etc.

This is not the case. We're actually NOT installing Finance, Typing Turtle and others as RPMs. You can have a look at this page, where we're outlining which activities are included and how they get installed: ​http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap

Would it be possible to install these via .xo instead of by .rpm?

This is already being done. The goal was to have the fructose activities around and install those via RPM (which is being done by selecting the sugar-desktop group now) and put some more honey activities as .xo in, which is exactly what we're doing. Have a look at the kickstart file, specifically the %post --nochroot part here: ​http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/sugar.ks

It should be as simple as replacing the 'rpm -i' commands for activities in the kickstart with 'wget <url> && unzip <xo file>'

See above. As a side-note, I plan to include wget on the image, tough, as it has been requested several times.

[sdz]

Replying to garycmartin:

If we're really going to stick with a sub-set of Activities that no (normal) user can erase or upgrade, we should at leased file a critical blocker against the Sugar component for either an alert message if a user attempts to erase a locked activity, or that the erase palette option is disabled (greyed out) for root locked activities. Not too sure where warnings should go when a user blocked from upgrading a root locked Activity. What do others think?

You can just run 'yum remove {put the name of the activity you want to get rid of here}', but for that, you need obviously root. +1 for the message thing - I like the greyed out solution even better. But in this case, this is urgent, as we're quickly approaching our deadlines for the SoaS beta release.

A last point: Ideally, users should be able to get the latest activity as a RPM, but that's just not always the case.

[tomeu]

I think the problem is that by the way that .xo bundles are installed, they aren't removable.

Any chance we can install them in $HOME and make them owned by liveuser?

I'm opening this again because from Sebastian's words seems like it wasn't intentional that none of the preinstalled activities cannot be upgraded or removed.

[tomeu]

This seems to work:

diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 49d4e77..b222fc7 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -155,6 +155,9 @@ class ActivityPalette(Palette):
         self.menu.append(menu_item)
         menu_item.show()
 
+        if not os.access(self._bundle.get_path(), os.W_OK):
+            menu_item.props.sensitive = False
+
         registry = bundleregistry.get_registry()
         self._activity_changed_sid = registry.connect('bundle_changed',
                 self.__activity_changed_cb)

[tomeu]

Fixed by ​http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/03605744

[sascha_silbe]

Bulk change distribution=SoaS -> component=SoaS