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
stalled Fedora reviews
Hi All Just going through the package reviews in Fedora related to olpc/sugar. The following are either stalled or closed due to lack of response from the reporter. Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 I'm not really sure of the exact reasons for the stall. I know I was watching the first 3 and haven't seen a response for a while. Is someone able to take them over (I can assist or review if necessary) or if they're no longer wanted let me know and I'll close them. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Wed, 2009-06-24 at 15:08 -0400, Paul Fox wrote: > the input devices /dev/input/event[012] (which currently report > on power button, ebook, and lid events) are also implemented in > olpc-pm.c -- i'm not sure what their fate might be. The end-user interface for those is unlikely to change much (if we do the ACPI tables right). On any modern non-XO laptop run: cat /proc/bus/input/devices You'll usually see ACPI-backed input devices for the lid and power button. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
1.5 power management, input events, wakeup events
i was mildly surprised today in a conversation with chris ball when he implied that the contents of our current (gen1) /sys/power directory would probably be going away in 1.5. or, more specifically, he said that arch/x86/kernel/olpc-pm.c would be going away, and that the wakeup_events and wakeup_source mechanisms would be quite different. principally, the plan is apparently to rely on ACPI mechanisms where possible. the input devices /dev/input/event[012] (which currently report on power button, ebook, and lid events) are also implemented in olpc-pm.c -- i'm not sure what their fate might be. so: i'm hoping someone (deepak? chris?) can write up a sketch of how they think power management, those input devices, wakeup events, etc, will work on 1.5. direct comparison to 1.0 would be helpful. (and of course a tie-in to specific work-to-be-done and/or modules-to-be-written would be helpful too.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
xs-activation updates
I just published a new xs-activation rpm that wraps up all the recent work for around antitheft. A nice wikipage is in the works, but for now a quick summary will do: - serves over port 191, and http (using the OAT protocol) - serves "root" leases, and also serves delegated leases, created on the fly with a configurable length of validity (within the bounds of the delegation, naturally - over OAT, it signs its messages with a delegated OAT key - it serves more complete messages - can serve "stolen" messages over both protocols (the laptop can be marked as stolen from Moodle) - knows how to import leases, lease delegations, oat delegations and "server keys" from appropriately prepared USB disks - has a modest privilege separation scheme where the private key is only root readable, and the signing process is abstracted from the actual server daemons - works well with the oat client code. - low-level logging goes to user.log, "high level" logging goes to Moodle's logging facility. - keeps data on "last seen" times for each client hth, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: update mechanism for new releases
> RPM is unfortunately a disaster in this space. If an rpm transaction > fails, there are no sane ways to recover it. On XO-1 a full OS update > transaction with rpm will take a very long time, so it's highly > likely that it will be interrupted. RPM and yum hackers treat this as > an intractable problem. yum has a feature now that allows you to complete 'transactions' I discovered the hard way that this actually works quite well :-) > This is, IMO, the actual showstopper. If we had a fs that could handle > snapshotting, then we could snapshot the system before starting the > RPM transaction, and have recovery hooks in the boot partition or in > initrd. There's been discussion on fedora-devel about hooking up yum > with btrfs transactions We do this at work on our SANs for major upgrades "snap restore backup-x" reboot :-) > - Upstream has not historically supported yum-based upgrades, only > anaconda upgrades. Yum OS upgrades are a relatively new (and risky) > thing. We could have an 'anaconda boot' partition to handle upgrades > without external media. Sounds like preupgrade. But in specific deployments where you know exactly the current software versions and the hardware it would be fairly easy to test and verify a 'yum upgrade'. > - Disk space requirements for olpc-update vs yum/rpm are probably > similar, and I suspect that during the upgrade rpm transaction the > footprint is larger for the rpm methods. We could teach olpc-update to > jettison the old image as soon as the new one boots successfully... > > - olpc-update completely sidesteps %pre and %post scripts -- this is > potentially a problem. > > - olpc-update offers downgrades, but our software at higher layers > doesn't support this. The Journal format upgrade broke downgrades in > the last OS upgrade. Sugar 0.84 has another Journal format change, > probably with a similar upgrade-only path. > > - deltarpm-style tools are of little benefit for a whole OS upgrade. > as there is little or no overlap between releases. Where there is > overlap, then olpc-update's hardlinking strategy is also a win of > similar proportions. Deltarpm-style tools usually force you to keep > around the original rpm as well. I think it uses the actual installed files so there's no need to keep the actual rpms around. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: update mechanism for new releases
> We have a bug open here which is a difficult question, in my opinion: > http://dev.laptop.org/ticket/9349 > > For the upcoming XO-1.5 software build (which will hopefully make it > onto XO-1 in the near future), do we want to ship olpc-update or use > standard Fedora technologies? > > > My unconclusive thoughts and questions: > > > olpc-update has some features which aren't available elsewhere, such as > the ability to switch between 2 OS builds installed on the same disk. > However, I've never seen or heard of this being used in the field. > > olpc-update is a "deployment quality" system in that it has covered > everything - not only from being an updater, it has olpc-update-query > which implements logic to figure out when to ask for updates and where > to ask for them. It's accompanied by the theft deterrence protocol and 3 > different server-side implementations of that. It's been implemented in > OLPC deployments. > > olpc-update creates a huge mass of hardlinks on disk, one for every file > on the main OS. It then rsyncs in the updated files on a copy-on-write > basis. Therefore you end up with a hell of a lot of hardlinks, and 2 > complete copies of every file that has changed. (this means it is not > great for situations when a lot of files have changed, e.g. changing > between major Fedora releases) > > olpc-update presents challenges for deployments that customise their > images. Namely, to produce a build that it is possible to olpc-update to > involves quite a bit of hassle (inserting security keys into the > firmware of each XO, setting up an OATS server, etc). We did manage to > figure this out in Paraguay (thanks to the internet connection, since it > wouldn't be safe to put the OATS server in the schools) and I improved > some tools accordingly. > > We've switched to dracut for our initramfs, meaning that the > initramfs-level stuff for the olpc-update system needs to be > reimplemented. Basically we have to wrangle with the strange /versions > filesystem layout and "frob" the /versions/current symlink if the user > is switching between versions. I have reimplemented this logic in a > dracut module but it is completely untested. > > > > The option for using "Standard Fedora technologies" as far as I am aware > is to basically use "yum update" in a fashion somehow suited for > deployments. > > Before F11, this would have meant a lot of downloading as each RPM > update was downloaded in full even if only a little bit changed. As of > F11, Fedora is now joining the "only download the bits that change" > movement with yum-presto and deltarpms: http://lwn.net/Articles/329484/ > > The deltarpm description on that lwn article leaves a little to be > desired -- it wouldn't work with big packages (is the quoted 200mb the > compressed or uncompressed size?), the reconstruction from deltas is a > CPU intensive task and we have a slow CPU, and it's all done in memory > and we don't have a huge amount of memory especially on XO-1. > olpc-update has an overhead of about 5 minutes of checksumming files. Well it works fine for OpenOffice and that's probably about the biggest package I have on my F-11 system. The file size might be a restriction to keep the memory usage in check. The thing with deltarpm is ultimately its a decision between bandwidth usage and memory usage. If all the updates are coming from a local school server and there's only a few updates a month its probably better going with the complete rpms. If bandwidth is an issue then drpms might well be the way to go. Fortunately its easy to enforce from the server side so you could include the deltrarpm support on the client side and if its not wanted just don't make the drpms available from the server. > Even though olpc-update isn't great for doing big distro updates > (because of storing 2 copies of changed files, in this case almost all > of them), it worked in those situations. I've never attempted an > RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that > work out for regular Fedora users? I've never had a problem with it. I've used it to remotely update my australian server from F-7 -> F-11 (not at once), and never had an issue with it. I've done it without issue on my local London firewall as well (a Fit-PC which runs the same style Geode a the XO). The main issue is that Fedora only tests upgrades between supported versions. So they "support" yum upgrades to F-11 from F-9 and F-10. > "yum update" always seems to use a surprising amount of bandwidth, > redownloading entire package databases just to see if anything new is > available. olpc-update was much more efficient in this respect, sending > only a 128-byte hash of the filesystem contents file to the OATS server. > For rpms, is there a more efficient alternative for updates-checking in > situations where there is only going to be e.g. 1 update per month? This should have improved greatly from F-9 to F-11. As for more efficient, not that I'm aware of but if t
[Invitation] Activity Team Meeting @ Fri Jun 26 1pm – 2pm (devel@lists.laptop.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090626T17Z DTEND:20090626T18Z DTSTAMP:20090624T040201Z ORGANIZER;CN=Sugar Labs Meetings:mailto:h9cfuk10894em7a8moemquu...@group.ca lendar.google.com UID:1otu9cnhhqd7s7a19i3n9kc...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=de...@lists.laptop.org;X-NUM-GUESTS=0:mailto:devel@lists.laptop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=i...@lists.sugarlabs.org;X-NUM-GUESTS=0:mailto:i...@lists.sugarlabs .org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=sugar-de...@lists.sugarlabs.org;X-NUM-GUESTS=0:mailto:sugar-de...@l ists.sugarlabs.org CLASS:PRIVATE CREATED:20090624T040200Z DESCRIPTION:http://webchat.freenode.net/?randomnick=1&channels=sugar-meetin g&prompt=1\n\nAgenda\n- How to move forward with updating Activities via AS LO. Should at\nleast be on roadmap to synchronise work and expectations.\n- Reduce redundant information on w.sl.o\, w.lt.o and ASLO. Factors to\ncons ider:\n -- Expectations of existing user base.\n -- Update mechanism at e xisting deployments.\n -- Reduce overall confusion.\n -- Reduce workload on Activity developers.\n -- Scalability of solution.\n\nView your event a t http://www.google.com/calendar/event?action=VIEW&eid=MW90dTljbmhocWQ3czdh MTlpM245a2M4NzggZGV2ZWxAbGlzdHMubGFwdG9wLm9yZw&tok=NTIjaDljZnVrMTA4OTRlbTdh OG1vZW1xdXVzbWdAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTg3YmEyMDZjYjg4ZjE4ZmM3ZGM xNTNhZjI5NmZlYzllM2RhNjRiNDc&ctz=America%2FNew_York&hl=en. LAST-MODIFIED:20090624T040201Z LOCATION:irc://irc.freenode.net#sugar-meeting SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Activity Team Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[SugarLabsPR-en] Sugar Labs Announces Immediate Availability of Sugar on a Stick; Learning Platform Runs on Any PC or Netbook In The Classroom
Sugar Labs Announces Immediate Availability of Sugar on a Stick; Learning Platform Runs on Any PC or Netbook In The Classroom LinuxTag, Berlin, June 24, 2009: Sugar Labs™, nonprofit provider of the Sugar Learning Platform to over one-million children worldwide, announces the immediate availability of Sugar on a Stick v1 Strawberry. Available free for download at www.sugarlabs.org, Sugar on a Stick can be loaded onto an ordinary 1GB USB flash drive and used to reboot any PC or netbook directly into the award-winning Sugar environment. It runs on recent Macs with a helper CD and in Windows using virtualization. Sugar on a Stick is designed to work with a School Server that can provide content distribution, homework collection, backup services, Moodle integration, and filtered access to the Internet. Today's Strawberry release is meant for classroom testing; feedback (feedb...@sugarlabs.org) will be incorporated into the next version, available towards the end of 2009. "One year after its founding, Sugar Labs is delivering on its education promise for its second million learners," commented Walter Bender, founder and executive director. "Sugar is preferred because it is a superior learning experience for young children: engaging while being affordable. Sugar on a Stick is a great way to try Sugar without touching your computer's hard disk. It is also well suited to slower, older PCs and low-powered netbooks. There is a version for the OLPC XO-1 and it will ship with the newer XO-1.5 laptops in the fall." Sugar on a Stick provides a coherent and consistent computing experience. It reduces costs by providing flexibility in hardware choices, allowing schools to keep their existing investment in hardware. Learners can benefit from the increased household ownership of computers; by bringing Sugar on a Stick home, every student has a consistent, comparable computing environment that parents can share in as well. It also provides off-line access to applications and content as not every learner has Internet access at home. As part of an ongoing effort to make Sugar on a Stick classroom-ready, Sugar Labs has been awarded a $20,000 grant from the Gould Charitable Foundation to implement Sugar at the Gardner Pilot Academy, a public elementary school located in one of the most culturally and linguistically diverse sections of Boston, Massachusetts. Learning Activities are at the heart of Sugar. Sugar on a Stick includes 40 Activities to interest young learners such as Read, Write, Paint, and Etoys. Hundreds more Activities are available free for download at the Sugar Activity Library (http://activities.sugarlabs.org). Most "Sugarized" Activities have student collaboration built-in; students and teachers work, play, and learn on the same Activities together. The Sugar Learning Platform is open, so by leveraging the work of other open source projects, existing software for children can be integrated; for example, the acclaimed GCompris suite of 100 Activities developed over the past five years by Bruno Coudoin was recently added to Sugar, including Activities such as Chess, Geography, and Sudoku. Teachers and parents interested in Sugar's Activities and its modern interface for children can watch short videos on the recently opened Sugar Labs Dailymotion channel (http://www.dailymotion.com/sugarlabs). Visitors to LinuxTag are welcome to speak with Sugar Labs contributors at booth 7.2a 110a. image: http://www.sugarlabs.org/press/Sugar-on-a-Stick-Strawberry.png For more information, please contact: Sean Daly, Marketing Coordinator website: www.sugarlabs.org e-mail: p...@sugarlabs.org telephone: +1-857-254-1100 Mailing address: Sugar Labs c/o Software Freedom Conservancy 1995 Broadway,17th Floor New York, NY 10023-5882 USA About Sugar Labs Sugar Labs, a volunteer-driven, nonprofit organization, is a member project of the Software Freedom Conservancy (conservancy.softwarefreedom.org). Originally part of the One Laptop Per Child project (www.laptop.org), Sugar Labs coordinates volunteers around the world who are passionate about providing educational opportunities to children through the Sugar Learning Platform. Sugar Labs celebrates the founding of the first Sugar Local Labs in Colombia, South America and Washington, DC. Local Labs will provide valuable connections between Sugar Labs communities and schools evaluating and learning with Sugar. Sugar Labs is supported by donations and is seeking funding to accelerate development. For more information, please visit www.sugarlabs.org. Sugar Labs is a registered trademark of the Software Freedom Conservancy. Other names are trademarks of their respective owners. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: update mechanism for new releases
>> For the upcoming XO-1.5 software build (which will hopefully make it >> onto XO-1 in the near future), do we want to ship olpc-update or use >> standard Fedora technologies? > > Due to the fedora lists' draconian 'reply-to' settings, the thread has > now moved to fedora-devel. > > Just mentioning it so that people (who may not be in both lists) can follow > it. > > (And cross your fingers, maybe one day fedora lists get their reply-to > fixed ;-) ) Well, actually, that's *my* fault... I first replied only to Daniel, letting the lists out. Then I wanted to correct my mistakes and transferred my answer to the lists. I saw "devel" and so I sent to fedora-devel instead of de...@laptop.org :-/ So there might be issues in the "reply-to" settings of the Fedora lists, but the problem actually came from "reply-to" issues in my GMail :) Sorry about that (even though this actuallly lead to some interesting talk) -- Mathieu Bridon (bochecha) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SocialCalc 0.8.3g version release
Bastian, we have not started localozation.. will soon! I have the instructions for sensors. I will be sending things soon!! Best, Claudia On 6/23/09, Bastien wrote: > Claudia Urrea writes: > >> Congratulation on a great work. I look forward to the localization in >> Spanish. You will be hearing from me soon!! > > And I look forward the translation in french! I looked into the code, > but wasn't able to find any po/ directory -- hope this will be available > soon... > > In the meantime, I've uploaded a tiny screencast here: > > http://vimeo.com/5291250 > > It doesn't really explore SocialCalc, it just exposes it to the eyes. > But still, some eyes can't *believe* things until they are shown them. > > -- > Bastien > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: update mechanism for new releases
> The main point, where olpc-update wins without a shadow of a doubt, is > failure-friendliness. Assuming a fail-safe filesystem, olpc-update can > be interrupted (hard) at any point, might take N runs to complete. And > will only switch to the 'new' image once it's completed in an atomic > operation. > > RPM is unfortunately a disaster in this space. If an rpm transaction > fails, there are no sane ways to recover it. On XO-1 a full OS update > transaction with rpm will take a very long time, so it's highly > likely that it will be interrupted. RPM and yum hackers treat this as > an intractable problem. Have you tried the « yum-complete-transaction » tool ? It comes from the yum-utils package and might interest you :) > This is, IMO, the actual showstopper. If we had a fs that could handle > snapshotting, then we could snapshot the system before starting the > RPM transaction, and have recovery hooks in the boot partition or in > initrd. There's been discussion on fedora-devel about hooking up yum > with btrfs transactions I probably am way over my knowledge, but what about LVM snapshots ? > - olpc-update offers downgrades, but our software at higher layers > doesn't support this. The Journal format upgrade broke downgrades in > the last OS upgrade. Sugar 0.84 has another Journal format change, > probably with a similar upgrade-only path. Yum/RPM also have downgrades. See the « yum-allow-downgrade » plugin and the « --oldpackage » RPM option. I'm don't know if those cover all the use cases you might have for downgrades though. -- 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
> - 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- > - 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
> 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
