[Nix-dev] Re: Libre Software Meeting talk about NixOS

[Jeff Johnson]

On Jul 10, 2010, at 6:58 PM, Ludovic Courtès wrote:

> 
>> The killer design issue is scripting with --rollback. Its extremely
>> hard to permit general scripting side-effects whose effects can ALWAYS
>> be reversed by --rollback.
> 
> You’ve already partly answered.  :-)
> 
> Are you saying that RPM-based distros already allow ‘--rollback’?  Or
> that the RPM package manager has a ‘--rollback’ option that happens to
> work *if* packages are side-effect-free, etc.?  Are upgrades atomic?
> 

What RPM-based distros do has no single answer.

RPM has had *THREE* implementations of --rollback now, each based
on experience with the previous version.

Its --rollback v2 that is sending SMS in Brazil. The major change there was
to add doubly linked upgrade chains. Each upgraded package includes
backward links to the package(s) that it erased, each erased package
(re-rolled into a *.rpm with the content that was present at time of erasure)
includes forward links to the package(s) that caused erasure.

With a doubly linked upgrade chain, and sets of packages marked with a transaction ID,
all the necessary elements to move forwards <-> backwards through time are
present.

Yes scripts have general; side effects that can do anything, including
	rm -rf /
that cannot be predicted or rolled back or anything else. But the mechanism
is known to work with some quite modest and reasonable restrictions on
scriptlets (like no typoes, duh!).

The latest version (presented briefly @FOSDEM 2010, you really
can't say much in 45 minutes about --rollback) is
	Transactionally Protected Package Management
aka TPPM or "RPM ACID". In a nut-shell, the side effects of
package management are broken into 2 categories
	1) databased ACID (yes the traditional technical term, fully implemented, level 2 isolation)
	2) syscall ACID (i.e the set of operations to install package payloads
	on file systems like write(2) and mkdir(2) etc. Prototyped using the
	abstract log mechanism within Berkeley DB extended in simple ways so
	that, say, rmdir(2) reverses mkdir(2). Content goes into the log
	before it goes onto the file system which is a bit bloaty but
	eaxctly what is entailed with --rollback insturmentation).
	3) scriptlet ACID this is the piece that Mancoosi WP3 is focussed
	on, modeling and simulating common debhelper-like scriptlet operations
	for transactional logging. Also presented @FOSDEM 2010 and actively being
	worked on).

But sure --rollback is entirely a fiction if, say, you attack the physical media
on which the transactional store resides. Kinda hard to run a --rollback mechanism
from a dead hard drive imho, but whatever ...

... and the answer to attacks on physical media where the transactional log
resides will be to tie the mess into a Cassandra distributed store. Which lurks
1 or 2 slots down on my RPM todo++ list, I've gotten side tracked into crypto
land since May (keys.rpm5.org SKS keyserver and more) and am just starting
to get back to TPPM development.

But the killer design flaw for --rollback is _STILL_ general scriptlet side-effects,
which are highly non-trivial to reliably invert generally. But the class of
debhelper-like scripts (~55 scripts, avg length ~3 lines, see Joey Hess's
measurements, this is just what I recall) can be modeled/simulated and made reliable
using a DSL as in Mancoosi WP3.

hth

73 de Jeff