update mechanism for new releases
pbrobinson at gmail.com
Wed Jun 24 06:12:00 EDT 2009
> 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.
More information about the Devel