update mechanism for new releases

[Peter Robinson]

>> 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