- rpm-based packages cannot be updated with Sugar's updater
utility,
which is the primary way for updating activities right now. There is no
upgrade path for activities installed by rpms (without updating the
whole OS, which is another open question)
You can update only one activity with:
# yum update sugar-<activity>
- There is certainly room for improvement in future, but finding
development time in the short term may be a bit tricky... or perhaps we
will be able to raise community interest in making or implementing a
plan for improvement... :)
I proposed the following some times ago [1], but no one responded. I
would have loved for someone actually knowledgeable (i.e. not some
random guy like me throwing out ideas he can't even implement) to
explain how this would be a terribly bad idea :)
Here it is again.
========================================
A). If all Activities were distributed as .xo bundles through the
Sugar
platform (such as access to
activities.sugarlabs.org), distro packagers
would only have to worry about keeping the core Sugar and it's dependancies
up-to date, not all the faster changing stuff.
B). If all Activities were distributed through distros, then Activity
authors would only need to worry about getting their source bundles to
distro packagers in the most friendly way. Sugar core would need some distro
agnostic or configurable user interface for yup/rpm/aptitude
installing/removing; but would not need to maintain code behind something
like
activities.sugarlabs.org.
Well, one could see the problem as follows :
1. activities installed via .xo bundles take precedence over
activities installed via the OS package manager (yum here), just like
config files in your home directory take precedence over the system
ones
2. use PackageKit for the distro agnostic part. On Fedora for example,
PackageKit comes with a yum backend. On Debian, it would come with an
apt backend. You can then have your own graphical package manager in
Sugar using the PackageKit APIs, no matter what the underlying OS is
(given that there is a PackageKit backend for this OS).
3. as a bonus, it would be nice to see if PackageKit can handle
multiple backends on a same system. This way, you could also have a «
.xo » backend for PackageKit that would simply take .xo bundles from
activities.sugarlabs.org (just like yum takes .rpm packages from the
repositories). This way, in the same graphical interface, you can both
install/update/remove the system packages and the .xo bundles
Now, I have no idea if that's even doable with PackageKit (the double
backend part), but that could be a lead worth chasing.
After that, if a distro chooses to package the activities, that's
great, because you have some kind of a « stable fallback set » on
which the user can fallback if he played too much with the .xo bundles
to have newer stuff. But he still can do it if he wants to try out
activities not available as RPMs, or if he wants to play with the
latest update that didn't make it to the distro repositories yet.
And if later on Sugar decides to stop one packaging effort or the
other, just disable one of the PackageKit backends and use the other.
========================================
Regards,
[1]
https://www.redhat.com/archives/fedora-olpc-list/2009-June/msg00005.html
----------
Mathieu Bridon (bochecha)