update mechanism for new releases

[Seth Vidal]

On Tue, 23 Jun 2009, Colin Walters wrote:

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

And we've still not handled the "upgrading daemonX changes the db format 
in a backward incompatible way." problem.

-sv