Hopefully this will not get in anyone spam folder.... Are we still trying to package honey activities for Fedora? I have an open-review for paint.. and if the plan is to get them in I am happy to finish it. However, if the plan is to upgrade via .xo I am happy to close it out.
-- bk
Hi Bryan,
On 3 Jun 2009, at 20:03, Bryan Kearney wrote:
Hopefully this will not get in anyone spam folder.... Are we still trying to package honey activities for Fedora? I have an open-review for paint.. and if the plan is to get them in I am happy to finish it. However, if the plan is to upgrade via .xo I am happy to close it out.
Thanks Bryan, this is such a good question! As an Activity Team co-co- ordinator ;-) I'd so, so like to be able to have a clear message here for both Activity authors and packagers of Sugar components. Packagers have taken Sugar to so many distros in such a short time, and I know little of the packagers real needs and distro politic, but it does seem that both packagers and Activity authors are currently each doing extra steps.
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.
We have a foot on each side of this quagmire just now.
Regards, --Gary
-- bk
Fedora-olpc-list mailing list Fedora-olpc-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-olpc-list
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,
----------
Mathieu Bridon (bochecha)
Mathieu Bridon (bochecha) wrote:
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.
<Snip>
Look at the fun I caused :). I will still try to get my review done, if for no reason then it makes the out of the box install a bit nicer. Then we can see how the bits play out.
-- bk