rpm vs xo & activity updates

[Mathieu Bridon (bochecha)]

> - 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)