Just a quick summary of a discussion and a decision that we reached
on
IRC, which will hold at least for now with our XO-1.5 software builds.
Further input is welcome, although this is at risk of starting another
huge discussion...
Question: In the early XO-1.5 OS builds right now, we have a mix of
RPM-based sugar activity packages, and .xo files unzipped
in /home/olpc/Activities. Do we want to change?
- It would be a little unfortunate to ignore the hard work of those who
have been actively packaging the activities within Fedora.
- 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)
- We could somehow hack the updater to work with rpms, i.e. if it found
a newer .xo bundle it could unzip it over the top of the rpm-installed
files in /usr/share/sugar/activities, but this is nasty and would raise
many issues
- One flaw in the existing OLPC OS releases for XO-1 is that there's no
way for deployments to push automatic activity updates, because
olpc-update doesn't touch /home and the activity updater always has to
be invoked by the user.
- This flaw would go away with rpm-based updates, because whatever
"global" OS updater we choose would include these updates.
- Which leads onto the possibility that *all* activities could be
shipped as RPMs, the sugar control panel activity updater could be
deleted, and then this problem is solved -- but that's quite a change
- The easy option is to do what we've done before: ship activities
entirely as .xo bundles in /home/olpc/Activities
- We're going to go with this option for now, because it's quick and
easy and it's what we're already doing.
- 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... :)
If you moved to rpms you have a sugar repo for activites. Then using
PackageKit you could explicitly just update using that repo hence not
having to update the whole OS. You can then also weight the repos
dependent on whether you wanted OS Activities or the other repo to
take precedence, add in local school repos for local content updates
etc. The other advantage of that would be for the likes of debxo where
they can use the apt beckend for package kit so each distro doesn't
need to reinvent the wheel. RPM has also seen some massive
improvements in both speed and memory usage in the F-9 -> F-11
timeframe [2] as well which would help.
From the development perspective PackageKit has all the python
bindings etc so that should help speed things over doing it from the
ground up.
From the global update side of things you could then use spacewalk [1]
on the school server which can be used to manage both OS and
Activities updates.
It would also solve the issue if various Activities need binary
components which I believe some have had.
Peter
[1]
http://www.redhat.com/spacewalk/
[2]
http://laiskiainen.org/blog/?p=19