update mechanism for new releases

[Mathieu Bridon (bochecha)]

> The main point, where olpc-update wins without a shadow of a doubt, is
> failure-friendliness. Assuming a fail-safe filesystem, olpc-update can
> be interrupted (hard) at any point, might take N runs to complete. And
> will only switch to the 'new' image once it's completed in an atomic
> operation.
>
> 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.

Have you tried the « yum-complete-transaction » tool ? It comes from
the yum-utils package and might interest you :)

> 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

I probably am way over my knowledge, but what about LVM snapshots ?

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

Yum/RPM also have downgrades. See the « yum-allow-downgrade » plugin
and the « --oldpackage » RPM option.

I'm don't know if those cover all the use cases you might have for
downgrades though.


----------

Mathieu Bridon (bochecha)