Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

[Colin Walters]

Hi Simo,

On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:

> The reason is simple: lot's of software *changes* data as part of its
> normal functioning, including and often in rollback-incompatible ways.

I wrote and maintain a system that has been doing continuous deployment
of GNOME.  It's been running for over a year, and is nearing it's
10000th build.

I have "rolled" back many times - both on the server side, and on the
client side.  Here's one I *just did* a few minutes ago because vala git
master broke the build of gnome-calculator:

https://git.gnome.org/browse/gnome-continuous/commit/?id=32a52e53100e92aad5d2dfae969be82227322f49

That's me telling the system "please stop building git master, and
freeze to this specific commit".  All clients get that change when they
upgrade - OSTree cares not at all for version numbers.

The vala maintainers continue to work out the issue in git master, and I
continue to ship a working system.  Double win.

Now it's true, programs in GNOME do sometimes make the type of data
format transition you're talking about.  Evolution has done it at least
twice.

But you know what?  My real world experience has been that having the
ability to roll back has *far* *far* *far* outweighed the downsides when
applications do format transitions.  It's comparatively rare.

Far more people are bit by things like hardware-specific issues where
gnome-shell fails to render on this particular card - and rollback works
beautifully for that.