Hi, On Tue, 21 Mar 2017, Dimstar / Dominique Leuenberger wrote:
Don't get me wrong: I like the fact that people DISCUSS about the solution and potential issues they see. And I'm sure Thorsten agrees on that too. Just don't always phrase everything in a way stating that all the new stuff just is more broken than all the old broken stuff.
Well, I'll try, but unfortunately I think this is actually the case :-/
GNOME upstream tries to eliminate this by downloading all the updates to the local cache, reboot the machine to a minimal running system, update all the packages and reboot the system into a working system (unlike Windows, though, it does NOT tell you when you have to do it: you actively click on 'reboot and update' from within GNOME Software or select the checkbox 'perform updates on next boot' when you reboot/shutdown your system) - of course everybody complains that booting to apply updates is not what we are used to do on Unix/Linux, and if you understand the setup well enough, you can actually judge on it - most 'users' I tend to talk to would not know how to get started.
Transactional Updates does a similar thing, from the other angle: update a snapshot that you will boot to once the update is complete. Of course, just like GNOME's approach, it also requires you to reboot the system. And in plus it requires a very strict separation of program files managed by the package manager from the data part (as would be the case with rollback).
So, from the reboot-is-necessary aspect, both are equivalent. People will either dislike this or not, but the same for both. Also the time for the activation of new stuff is the same (at reboot). So the difference is only how the new bytes becomes activated. With initrd/Windows/GNOME approach: installed on top of whatever was there at reboot time; transactional-updates: _replacing_ whatever was there at reboot time with whatever was there at reboot-time minus $arbitrary_time plus updates. I mean, it seems so very obvious to me that the latter is the worse of the two.
I'm not yet sure if any of the methods being implemented / tested at this moment will give us ALL solutions to all problems... but exploring the options is certainly the way to go. No shame in admitting at one point 'oh well, that did not work out as expected - but we learned this and that about the problem'
Fair enough. Experiments certainly will provide real knowledge instead of mere arguments :) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org