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