>> 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 Well its not supported completely, the simple fact that a lot of people use it means that its supported within certain constraints. The problem with preupgrade is that it needs user interaction and a lot of space. It downloads the distro update locally, reboots the machine and then runs anaconda. >> "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 ? Or it can be done like a standard Fedora release key which is pre imported which would mean that there's not need for confirmation. Peter -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
