http://bugzilla.opensuse.org/show_bug.cgi?id=1205258

Bug ID: 1205258 Summary: Multi-step transactions for transactional updates Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: All OS: openSUSE Leap 15.5 Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: contact@ericlevy.name QA Contact: jsrain@suse.com Found By: --- Blocker: ---

Transactional updates, available as an installation option in Leap, ensures that each change to the system is captured and recorded within a transaction. However, the limitation, compared to normal systems, is that system changes cannot be tested for their practical effect until after a system reboot. Afterward, if any problems are found, the transaction must rolled back, and the change must be attempted again, after another reboot. Such a process is particularly cumbersome if the outcome of a change would not be determined until it would be tested in practice.

Proposed is a mechanism for opening a transaction, which would remain open after the completion of the command opening it. Further commands would then allow entry into the open transaction, either in read-only or read-write mode, until the transaction is finally closed.

For example, one might consider consider the following command sequence:

1. sudo transactional-update begin 2. sudo transcational-update enter -w a. sudo zypper ins somepackage b. exit 3. sudo transactional-update enter a. cd ~/project b. make c. exit 4. sudo transactional-update commit

In the sequence, the user has requested that a new transaction be opened. It will remain open even after the command completes. The user has then entered the environment of the transaction, with the ability to modify the system. The tool creates a shell in the isolated environment, in which the user has selected a package for installation, and then has exited. The transaction remains open even after the shell closes. To test whether the system modifications carry the desired effect, the user has entered again into the transaction environment, but without the ability to modify the system. The user has then attempted a build process, in the modified system environment, to determine whether the system changes have had the desired effect. In this environment, the installed package is available, though not on main system. The user has finally exited the environment, and then committed the system changes. (Alternatively, the user may have destroyed the transaction, if needed.)

After the transaction is committed, it represents the system state for the next boot session.

In a normal system, a user may install packages or make other system changes, and test the effects immediately. The user may then make further changes, or reverse earlier ones, again, with immediate effect. The proposed enhancement allows the same capability in an isolated environment, which is optionally committed for the next boot cycle.

It is possible to achieve a comparable effect by simply adding a read-only option to the tranactional-update command. This option could be combined with the continue switch. However, explicit semantics for the use case is likely to reduce the incidence of human error and ensure best practices.