update mechanism for new releases

[Peter Robinson]

> RPM is unfortunately a disaster in this space. If an rpm transaction
> fails, there are no sane ways to recover it. On XO-1 a full OS update
> transaction with rpm  will take a very long time, so it's highly
> likely that it will be interrupted. RPM and yum hackers treat this as
> an intractable problem.

yum has a feature now that allows you to complete 'transactions' I
discovered the hard way that this actually works quite well :-)

> This is, IMO, the actual showstopper. If we had a fs that could handle
> snapshotting, then we could snapshot the system before starting the
> RPM transaction, and have recovery hooks in the boot partition or in
> initrd. There's been discussion on fedora-devel about hooking up yum
> with btrfs transactions

We do this at work on our SANs for major upgrades "snap restore
backup-x" reboot :-)

>  - Upstream has not historically supported yum-based upgrades, only
> anaconda upgrades. Yum OS upgrades are a relatively new (and risky)
> thing. We could have an 'anaconda boot' partition to handle upgrades
> without external media.

Sounds like preupgrade. But in specific deployments where you know
exactly the current software versions and the hardware it would be
fairly easy to test and verify a 'yum upgrade'.

>  - Disk space requirements for olpc-update vs yum/rpm are probably
> similar, and I suspect that during the upgrade rpm transaction the
> footprint is larger for the rpm methods. We could teach olpc-update to
> jettison the old image as soon as the new one boots successfully...
>
>  - olpc-update completely sidesteps %pre and %post scripts -- this is
> potentially a problem.
>
>  - olpc-update offers downgrades, but our software at higher layers
> doesn't support this. The Journal format upgrade broke downgrades in
> the last OS upgrade. Sugar 0.84 has another Journal format change,
> probably with a similar upgrade-only path.
>
>  - deltarpm-style tools are of little benefit for a whole OS upgrade.
> as there is little or no overlap between releases. Where there is
> overlap, then olpc-update's hardlinking strategy is also a win of
> similar proportions. Deltarpm-style tools usually force you to keep
> around the original rpm as well.

I think it uses the actual installed files so there's no need to keep
the actual rpms around.

Peter