rpm vs xo & activity updates
david at lang.hm
david at lang.hm
Tue Jun 23 18:50:21 EDT 2009
On Tue, 23 Jun 2009, Daniel Drake wrote:
> 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... :)
can you configure an instance of rpm to run entirely under /home/olpc?
that way it could be run non-root, but still have all the abilities of the
standard tools (including the ability to poll for updates)
the activity rpms can be in a seperate repository so that the people
putting togeather a distro can choose to have them maintained by the root
package manager, or my the user package manager.
More information about the Devel