On 12/09/14 12:43, Matthias Klumpp wrote: > Now, if the user reboots, the system enters a special mode where > updates are installed using PK (progress is shown on Plymouth), then > it reboots again and enters the desktop.
I've done some work on a similar feature for unattended-upgrades <https://bugs.debian.org/741356>, which hasn't been merged by the maintainer yet, but is used in SteamOS. The major design difference there is that the upgrade is carried out during shutdown instead of having to boot into a special mode, so you don't have to reboot twice. We did consider applying upgrades during startup, but then you have to worry about whether all the necessary things got restarted afterwards (which is impossible for e.g. the kernel in any case); if you do it during shutdown, everything is about to be terminated anyway, so it doesn't matter whether processes with old libraries mapped are still hanging around. FWIW, we never considered *not* rebooting for upgrades - if it works, great, but working out all the corner cases, and diagnosing new ones when they happen, just didn't seem an efficient use of anyone's time. > Now, in case an offline-update was prepared and the user does an > online-update, the "reboot & install updates" sign will simply vanish, > and everything will behave like it always did. > This feature is meant for unexperienced users, so, as Steve pointed > out, it would have to be default - but even if it was, it would be > pretty non-invasive. I think this is a significant point. The sort of people who read debian-devel are the sort of people who can assess the severity of a security flaw on a scale from "drop everything and fix it now" to "apply eventually"; interpret checkrestart output; restart the necessary things; and recognise the symptoms of an online update to an application that cannot actually cope with online updates (and file bugs where appropriate). However, those people are not Debian's only audience. If I tried to explain all that to my parents, they'd never apply security updates. "When your computer says it has downloaded security updates, reboot next time it's convenient" is far easier to explain - it might sometimes be overkill, but doing too much is better than not doing enough. > Also, > if e.g. a bug in a shared library gets fixed which is used by many > programs, you would have to re-execute quite a lot of stuff. As much as I want to agree with the general philosophy that in an ideal world every piece of software would support re-exec'ing itself, we do not live in that ideal world. In an ideal world libraries wouldn't break ABI either, but they do; in an ideal world libraries and applications wouldn't have security flaws that need stable-updates, but they do. As much as I'd like people to implement all the subtleties of re-exec'ing from an arbitrary older version, it doesn't seem realistic to expect it to happen (and when it does, it'll be wrong - because as a first approximation, code that you don't test doesn't work, and upgrading from version < X to version >= X is the sort of thing you only do once or infrequently). When a significant or "core" enough bug has been fixed (e.g. Heartbleed, or a libc flaw), I would personally advocate ignoring checkrestart and friends, and rebooting anyway, even on a server: there is value in knowing for sure that everything that needs restarting has definitely been restarted, and whatever tool you used to find the necessary things to restart didn't miss any. "Obviously correct" is better than "reasonably sure to be correct". S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5412f527.7060...@debian.org
