Oops... My reply went only to Daniel, not to the lists :-/ ---------- Forwarded message ---------- From: Mathieu Bridon (bochecha) <bochecha@xxxxxxxxxxxxxxxxx> Date: Tue, Jun 23, 2009 at 20:33 Subject: Re: update mechanism for new releases To: Daniel Drake <dsd@xxxxxxxxxx> > 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? Lot's of people will tell you that it works fine. However, this is not a supported path for upgrade. Users should use Pre-Upgrade instead. See: => http://fedoraproject.org/wiki/Category:PreUpgrade => http://fedoraproject.org/wiki/Interviews/PreUpgrade > "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? You can configure yum to not update its cache that often with the « metadata_expire » directive in /etc/yum.conf > "yum update" has historically not worked very well on the XO. It hits > OOM, it fills up yum's cache and then aborts, it gets confused between > i586 and i686, etc. RPM has seen a lot of improvements in speed and memory consumption lately. My XO (a build from the latest G1G1 in Europe that I never updated yet) has RPM 4.4.2. Panu Matilain has just posted about that, comparing the performances of RPM from 4.4.2 (Fedora 9) to 4.7 (Fedora 11). Perfect timing :) => http://laiskiainen.org/blog/?p=19 Yum has also been improved. Not sure those improvements would be enough, but I bet the situation in Fedora 11 is already much better than it was in the previous OLPC builds from Fedora 9. > We would have to tweak yum's behaviour quite heavily.. I don't think we > want an rpm cache, or for it to keep the .rpm files at all. You can use the « keepcache » directive in /etc/yum.conf which AFAIU aims exactly at that. From « man yum.conf » : keepcache Either ‘1’ or ‘0’. Determines whether or not yum keeps the cache of headers and packages after successful installation. Default is ’1’ (keep files) What other customizations are you expecting ? > It introduces new questions of security, signing, etc. Deployments will > want to sign their rpm updates that they push out, so we now need a > mechanism for getting that specific RPM signing public key onto all the > laptops in a deployment so that they can trust the updates server. > We had this nailed down for olpc-update: deployments can insert "local" > public keys into the manufacturing through keyjector firmwares for > existing laptops, and Quanta can now manufacture laptops with these keys > already in place for future orders. olpc-update and the bitfrost code > used these keys to verify updates. Yum will ask the user if he wants to import the key and trust it on first use. Wouldn't that be enough for signing keys ? Couldn't Quanta manufacture the laptops with those GPG keys bundled too ? > For the XO-1 possibility it raises the question of how existing laptops > could be migrated to this new system, without losing their user data. Backup with a School Server ? Best regards, ---------- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
