update mechanism for new releases

[Colin Walters]

On Tue, Jun 23, 2009 at 4:41 PM, Martin
Langhoff<martin.langhoff at gmail.com> wrote:
> On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidal<skvidal at fedoraproject.org> wrote:
>> they're not insolvable - they are just very very very hard.
>
> :-)
>
> At the end of the day, if the OS doesn't give you atomic multi-file
> transactions, and your %pre/%post scripts aren't also written
> perfectly atomically, I would say that it _is_ impossible.

Well, it's pretty clear how to make the dual root approach work.
There was some work done on this way back in the Stateless project:
http://fedoraproject.org/wiki/StatelessLinux

Basically updates are applied into a side image, then on next reboot
the new image is targeted, and the old one becomes the new update
target.  Short of some deduplication work, this has the downside that
it doubles disk usage for the OS packages.

I'm pretty sure Windows updates do something like this but on the
filesystem level, where newly installed files don't actually overwrite
the ones of the same name, but are put into a "waiting" state where
the OS on the next reboot (befor elogin) will make them active.  I'm
not sure if that process is atomic - I bet it isn't, but it is a
smaller window for failure.

Besides the "I ran out of laptop battery during yum" problem, the
other one that we really do need to solve that's related is that many
applications can't handle files being removed under them.  Firefox's
versioned directories exacerbates this, but I've gotten weird failures
from plenty of running applications which expect glade files, images,
etc. from the old version to still be there.