Comment # 6 on bug 1205258 from Eric Levy

Thank you for the explanation. I had no idea about such support coming from
tukit. I had reviewed the manual for the command transactional-update, but I
have not found any comprehensive guide, tutorial, or manual for the overall
system, that is, the general design of the TU framework. I have generally found
only documentation for specific components, or high-level overviews of the
concept. 

A comprehensive document that targets the practical use cases for
administrators and users, would be very helpful. Elaboration of the inner
plumbing would be a helpful too, as an indispensable resource for disaster
recovery. To my mind, such a document would useful overall much more so than
just a blog post on this particular subject, especially because it may be hard
for the right person to find the resource at the time when needed. However, it
certainly might help someone at some time, and certainly would be more helpful
for the subject than any resource I have found so far.

Yes, I agree you found a flaw regarding the privileges of the user shell, which
could be resolved through appropriate modifications of the concept. You could
simply allow any user to enter the open transaction, with regular permissions.

At the present time, I feel compelled to push back against the idea of lack of
isolation being a major problem. Locations storing user data are meant to be
manipulated by operations initiated by the user, in ways that the user
understands. My motivation for submitting the request is that in a vanilla
installation, it is possible for the an administrator to install a package on
an active system, immediately interact with the modified system, and then, if
desired, reverse the system changes, or add new ones. Surely it is possible
that such a sequence would leave artifacts in data locations, but such effects
are well understood, and no more harmful in the transactional scenario than in
the classical one. 

For cases where some isolation is desired, you could consider adding an option
for providing the full environment through temporary snapshots, such that the
changes to these locations within the test session will be lost, even if the
changes to the system are committed. The purpose would be to test operations,
for resolving whether the new system image is one that would be useful for
future boot sessions, or not. For example, the build operation is reproducible.
If it succeeds in the test environment, it will succeed in new system
configuration, once it would become active. Please remember also, if I am not
mistaken, that rollback of a previous transaction will not roll back
modifications to data directories occurring during any boot sessions following
the transaction. Thus, you could be providing more isolation than available
currently, by opening the possibility for utilizing the system changes in a
special session.

My understanding would be that if an administrator must roll back a
transaction, any problems encountered would be the same as the ones that cause
you to hesitate on the idea I am proposing. The proposed method is simply a
means to test the consequences of a transaction before committing it for future
boot sessions, and without interrupting the boot session of the live system.
Once the changes are confirmed, and the transaction committed, then the system
would be rebooted, with predictable effects.

If I am not making some important oversight, you might consider supporting the
work flow through an accessible set of operations in the tool chain. I believe
the concerns I have raised originally are rather common, and without a way to
address them, it may be harder for many sites to adopt the system, or to find
ways to resolve unforeseen problems after adoption.