Very important,
And IMO almost impossible to fully understand immediately (I’m still digesting what I’ve been reading).
Aside from the broken link,
The working link links again to another mail list item that likely should be considered currently authoritative, and is the following
https://lists.opensuse.org/opensuse-factory/2017-01/msg00367.html
I can’t remember where at the moment, but sometime maybe a year ago I ran into another situation where a “transaction-update” was implemented… Was that in a containers running on a BSD system? Maybe git? – I can’r remember for sure. In that case, it also was a maze to understand the details of updating.
In any case,
I’m glad to see this despite its many caveats…
For a long time it’s bothered me that a big enough update could be interrupted leading to an unbootable system (on next boot). I’m sure I’m not the only one to have had an upgrade interrupted and wonder if the system would crash or boot successfully next time. Many times I’ve had a TW in storage and not booted for 9 mths or longer, tried to upgrade and the system was rendered unbootable.
So,
It seems that “transaction-update” is a first step to addressing the problem.
IMO the description that the process is atomic is partially misleading… My experience with atomic transactions (and the definition as I know it) is that if the transaction is unsuccessful, then the transaction is <automatically> rolled back. From what I’ve read, this does not happen, the flow stops on about step 3 of a 5 or so step process and you have to manually finish the rollback to effect, and in the meantime you’re in limbo. IMO automatic rollbacks are an important part of atomicity and if not now then should be a future objective of “transaction-update.”
The existing problems described by Thorsten (the author) are interesting…
Atomic transactions are usually implemented and described when talking about transforming individual datum whereas the concept is being applied to an entire partition containing many individual files. I don’t see the “atomic transaction” applied to individual packages but to a higher level, collection of files, and IMO this is possibly where an improved “transaction-update” needs to be re-designed… With the current approach, it’s hard to verify functioning integrity (which is different than file integrity where atomic transactions are more commonly applied), but that is possibly what has to be done… Similar to our current rudimentary package patterns, perhaps subsystems and subsystem functionality need to be clearly identified and if necessary modularized and then each updated/upgraded individually. The result would be literally “biting off only as much as you can chew” so that each subsystem can be upgraded and handled independently of another.
Anyway…
That’s enough musing for now on what should be a very important new feature,
TSU
Even more important is the fact that this is something unique to openSUSE and SUSE and can be a real differentiator.