[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: update mechanism for new releases

On Tue, 23 Jun 2009, Colin Walters wrote:

On Tue, Jun 23, 2009 at 4:41 PM, Martin
Langhoff<martin langhoff gmail com> wrote:
On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidal<skvidal 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:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]