Oops...
My reply went only to Daniel, not to the lists :-/
---------- Forwarded message ----------
From: Mathieu Bridon (bochecha) <bochecha(a)fedoraproject.org>
Date: Tue, Jun 23, 2009 at 20:33
Subject: Re: update mechanism for new releases
To: Daniel Drake <dsd(a)laptop.org>
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)