rpm vs xo & activity updates

[Peter Robinson]

> 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