Opened 12 years ago
Closed 9 years ago
#2452 closed enhancement (notsugar)
Sugar should not offer to upgrade system activities
| Reported by: | lfaraone | Owned by: | tomeu |
|---|---|---|---|
| Priority: | Unspecified by Maintainer | Milestone: | Unspecified |
| Component: | Sugar | Version: | Unspecified |
| Severity: | Unspecified | Keywords: | |
| Cc: | mattva01@…, jelkner | Distribution/OS: | Ubuntu |
| Bug Status: | Unconfirmed |
Description
At the Arlington Career Center, people have had problems when they upgrade system packaged activities to newer versions.
This sometimes breaks things in odd ways.
Ideally, Sugar should detect if an activity is installed globally and not offer the upgrade.
Change History (3)
comment:1 follow-up: ↓ 2 Changed 12 years ago by walter
comment:2 in reply to: ↑ 1 Changed 12 years ago by lfaraone
Replying to walter:
We have discussed this ad nauseum. The consensus (I'll look for the thread) was that we want to let users install new versions in ~/Activities/ but not over-write the installed versions in /usr/share. We also have support for a list of activities that cannot be deleted. That said, it sounds like the problem you are describing is better characterized by our not properly tagging a upgrade for which versions of Sugar it runs on and by our not bundling with the activity any dependencies that may be distro-specific. I'd suggest opening a new ticket specific to the activity that failed to install properly.
Sometimes is that XO-bundled activities that are not pure-python are bundling
dependencies that we *already package* in Ubuntu, but for some reason the
bundle's precompiled version is not binary-compatible with Ubuntu. From a
system distribution standpoint, we don't want globally installed activities to
be updated via the Sugar updater.
comment:3 Changed 9 years ago by godiard
- Resolution set to notsugar
- Status changed from new to closed
Now the updater is packaged separeated. The distributions can avoid instlling it,
and they will not have problems.
Closing as notsugar.
We have discussed this ad nauseum. The consensus (I'll look for the thread) was that we want to let users install new versions in ~/Activities/ but not over-write the installed versions in /usr/share. We also have support for a list of activities that cannot be deleted. That said, it sounds like the problem you are describing is better characterized by our not properly tagging a upgrade for which versions of Sugar it runs on and by our not bundling with the activity any dependencies that may be distro-specific. I'd suggest opening a new ticket specific to the activity that failed to install properly.