2014-09-12 1:49 GMT+02:00 Cameron Norman <camerontnor...@gmail.com>: > El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp <matth...@tenstral.net> > escribió: >> [...] > > What are the options? > > I would like if apps could say somehow (maybe an extension to the AppStream > format?) whether they need offline updates, or if online is fine, so that it > is only when needed. Also, an option to ignore apps' preferences and just do > always offline or always online should be present (in PK's configuration). That would probably be an overkill, although details like that could theoretically be stored in the AppStream/DEP-11 metadata.
> Is this how the feature has been implemented? Do you think upstream (and you > as an AppStream supporter / developer) would be enthusiastic about adding > this, if it is not the status quo? Possible, but unlikely - I don't think it's needed. Here is a brief explanation about what actually happens when "offline-updates" are enabled: the online-updaters will work as always, even PackageKit is able to perform online-updates like it always did. But if a desktop like GNOME (and I am really only talking about desktops here) recognizes updates, it will tell PackageKit to download updates locally. Whan that is done, the user is notified about available updates (and might be asked for reboot), or the shutdown button simple gets an "reboot & update" sign. 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. 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. Currently, GNOME-Software makes heavy use of offline-updates, and I don't know of anything else which does (except for the cli tools). The problem with restarting applications and subsystems is that you never know if the loose state information if you just restart them (e.g. Inkscape going down on upgrade would be pretty annoying). 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. On servers, I expect people to handle that and know about this, but for desktop users, I see some value in offline-updating. Restarting the whole system is a pretty pragmatic solution for the problem, you have to restart to use a new kernel as well anyway. One thing I personally disagree with is how this is implemented technically at time (we have systemd, which can reliably enter different targets (runlevels) and ensure services are started and stopped properly, but we still reboot twice "for safety reasons"), but Lennart has a different opinion (and admittedly some valid points about his position). Relevant things to read: http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ http://fedoraproject.org/wiki/Features/OfflineSystemUpdates One thing I want to highlight again is that this would be a pretty non-invasive change for users used to the existing behaviour, and that the decision to use it lies by the Debian desktop teams (KDE/GNOME) and their upstreams, which implement it or not. What I want to do for Jessie+1 is implement this reliably - it should better be working properly than being half-usable. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- 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/CAKNHny8=5vpoastacc2kl20vndnm3zvlsanhrcyym6khzek...@mail.gmail.com
