Hi, On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
If you clearly seperate data from applications, as you have to do for snapshot and rollback anyways, the risk is really very low. And if you use a read-only root filesystem, the risk is zero. But this are not only problems with transactional updates, you have the same problems already today if you use rollback. And there the risk of data lossage is much, much higher.
But a rollback always implies data-loss (namely all the data written since). That's known by people (at least by those that have some mental concept of "transactional"). Data-loss by activation of an update is surprising. What happens e.g. in this situation: % user installs update % user installs more updates % user adds repo and installs a new rpm foo % user reboots (because finally he's annoyed by the warning of having to reboot) foo is gone from the rebooted system, right (except of course for the desktop item for that program, now pointing to a dead file, which is even more surprising)? Are at least updates 1 and 2 merged?
But the system you are implementing sounds a more dangerous way of effectively downloading the update in the running system, rebooting, and at defined state (say, in initrd context) create the snapshot, install into it and continue booting from it.
That's how Windows is doing it and GNOME tries to implement it.
But the way Windows does it (I don't know about GNOME) is definitely more like a proper transaction than installing into a snapshot and just activating it at next reboot over whatever was there before. That's not transactional at all because the abort-transaction with concurrent writes is missing.
You should watch my presentation at Fosdem this year, which negativ impact this already had in the past.
Perhaps, are the slides somewhere? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org