Fwd: update mechanism for new releases

[Daniel Drake]

On Tue, 2009-06-23 at 21:10 +0200, Mathieu Bridon (bochecha) wrote:
> > 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

Interesting. So "yum update" does not sound like an advisable method for
making large changes.
I don't know enough about anaconda to say whether preupgrade would fit
into our design. It's not something we're using in our builds at the
moment.

> You can configure yum to not update its cache that often with the «
> metadata_expire » directive in /etc/yum.conf

So, if the cache has not expired, yum will not even go online and check
for new packages?

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

Good to hear, I hope you're right :)

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

Great, thanks for the pointer.

> What other customizations are you expecting ?

I'm not really sure.

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

>From my experience in the field, it's totally inappropriate to present
those kinds of questions to our users (young children). The child's
response will be random. We'd have to make that "yes" response for that
particular key be part of the build.

As for Quanta, they can tweak the manufacturing data very heavily but
they don't customise the image -- they need it provided as-is.

In the past, OLPC has made software images for deployments. Now we're
moving towards a model where the deployments build them using OLPC's
tools, or at least they customise "base" images that OLPC have made. But
it's tricky as the tools are young, the processes are a bit tricky, and
deployments don't usually have a huge amount of technical resources. 

It's possible, but is an additional complication that needs
consideration.

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

It's a possibility, but also leaves a lot of work to be done. Neither XS
or sugar has a full-journal restore interface. Not all deployments have
XSes either. It seems like that we should be able to do the upgrade
entirely locally if enough disk space is available.

Daniel