Re: rpm vs xo activity updates
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
- 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/msg5.html -- Mathieu Bridon (bochecha) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
Can you expand on this idea? My main complaint with what I've seen from previous non-OLPC mechanisms is that root/super-user privileges are required. We can wrap any old CLI in a shiny, pretty, GUI. But it needs to work in a sane, safe way without passwords for small human beings. If I'm not mistaken, PackageKit uses PolicyKit. And PolicyKit can be configured to either: - ask for the root password each time - ask for the root password and keep permission for the active session - ask for the root password and keep permission indefinitely - same 3 above cases but with the user's own password instead - always grants permission to the user - always deny permission to the user All those possibilities can be configured for a lot of different actions needing administration permissions, among which is « update my system » or « install new software ». :-) You can look at how it works by running the « /usr/bin/polkit-gnome-authorization » tool on a Gnome desktop. -- Mathieu Bridon (bochecha) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
Daniel Drake wrote: - 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... :) Daniel Have you looked at how ruby gems and rpms interact? I do not have a tremendous amount of experience, but it seems like the user can select either rpms or gems to update, and it just works. -- bk ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
rpm vs xo activity updates
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... :) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
On Tue, 2009-06-23 at 21:52 +0200, Mathieu Bridon (bochecha) wrote: - 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 This is not a suitable interface for our users. We need something easier, or something automatic. And any work in this direction would probably be bolting onto the sugar activity updater, making it really confusing with 2 backends or something, and sort-of calls out for a rethink of the system as a whole. Speaking of which... 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 :) snip.. I love these ideas. I would even go as far as to remove .xo support altogether as there are a number of flaws in that format now that sugar is hugely increasing in scope. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
Hi Daniel, On 23 Jun 2009, at 21:13, Daniel Drake wrote: 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 :) snip.. I love these ideas. I would even go as far as to remove .xo support altogether as there are a number of flaws in that format now that sugar is hugely increasing in scope. Can you expand on this idea? My main complaint with what I've seen from previous non-OLPC mechanisms is that root/super-user privileges are required. We can wrap any old CLI in a shiny, pretty, GUI. But it needs to work in a sane, safe way without passwords for small human beings. Regards, --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rpm vs xo activity updates
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. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
