Re: PackageKit cleanup: Do you use these functions?
On 2014-09-12 14:03, Guido Günther wrote: On Fri, Sep 12, 2014 at 01:43:01PM +0200, Matthias Klumpp wrote: [..snip..] 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, Why should it go down? It's mapped into memory already. There can be problems with plugins but it would make more sense to think about these details than resorting to rebooting (twice!). Btrfs could show a way forward here. With plugins and, say, dbus services. Btrfs could also show a way just like Nexenta did with updates and rollbacks to a known good state from grub using snapshots. Oh well. Restarting the whole system is a pretty pragmatic solution for the problem, you have to restart to use a new kernel as well anyway. There KSplice among others. [citation needed] Yes, there is. And kgraft and kpatch. But does anyone happen to know someone actively publishing patches for them? Kind regards Philipp Kern -- 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/7b9e9f0e019a9f6342849963e4c23...@hub.kern.lc
Re: PackageKit cleanup: Do you use these functions?
Hi, Steve Langasek: I understand that software (especially desktop software) not coping with online updates is an existing problem. Not only that. What _do_ you do when version 2 of $SUPPORTING_PACKAGE implements a broken/superseded API or protocol? You limp along; you either cannot start any new $DEPENDING_PROGRAMs or, when the supporter has been restarted, all the dependants instantly break. Unless you restart them too. We do some restarting for libc updates, but in a haphazard way (we don't shut them down _while_ updating, only for some daemons) and for no other package. The question is whether we - collectively - think moving to offline updates is an acceptable way to address this problem. The problem is that an offline updater is an attractive nuisance. It solves a specific problem which is now rare, precisely because we don't solve it and therefore spend time and effort to prevent the offline update non-solution from spreading. raise that question is now, /before/ it becomes an entrenched assumption and leaves our users with no choice but to use it because their desktops become unusably broken if you apply package updates while they're running. The problem is that some already do. Tried updating firefox ^W iceweasel lately? The irony here is that firefox already has a perfectly capable method of realising that there's a newer version available, and of re-exec'ing itself without any data loss. -- -- Matthias Urlichs -- 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/20140912081856.gc19...@smurf.noris.de
Re: PackageKit cleanup: Do you use these functions?
Matthias Urlichs matth...@urlichs.de writes: Hi, Steve Langasek: I understand that software (especially desktop software) not coping with online updates is an existing problem. Not only that. What _do_ you do when version 2 of $SUPPORTING_PACKAGE implements a broken/superseded API or protocol? You limp along; you either cannot start any new $DEPENDING_PROGRAMs or, when the supporter has been restarted, all the dependants instantly break. Unless you restart them too. We do some restarting for libc updates, but in a haphazard way (we don't shut them down _while_ updating, only for some daemons) and for no other package. The question is whether we - collectively - think moving to offline updates is an acceptable way to address this problem. The problem is that an offline updater is an attractive nuisance. It solves a specific problem which is now rare, precisely because we don't solve it and therefore spend time and effort to prevent the offline update non-solution from spreading. We should also not underestimate the feeling of control that online updates provide to users. I've often been told by new users that them deciding to click the Updates Available (or whatever it says) button, and upgrading their system, made them feel like they were in control of the computer for the first time in their lives. We should not discard that lightly. We should also not exchange bugs of the form I upgraded the software on my computer, which I think included an ugrade of $foo, and now $bar stopped working for $bar stopped working when I ran it [while not quite thinking: I would mention the fact that I rebooted last night if I though that was relevant, but I cannot imagine it is, so I won't] It's all too easy for individual developers to think that only allowing upgrades during reboots will be much safer for their particular application, so where's the harm? I'm sure that the folks at Microsoft are now very aware of the resulting harm, having been fighting to get away from the need for multiple reboots per upgrade for years -- Let's learn from their mistakes and not even start down that road. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpd6CiKLSWTE.pgp Description: PGP signature
Re: PackageKit cleanup: Do you use these functions?
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
Re: PackageKit cleanup: Do you use these functions?
On Fri, Sep 12, 2014 at 01:43:01PM +0200, Matthias Klumpp wrote: [..snip..] 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, Why should it go down? It's mapped into memory already. There can be problems with plugins but it would make more sense to think about these details than resorting to rebooting (twice!). Btrfs could show a way forward here. 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. We have at least three tools in Debian for that checkrestart, needrestart and whatmaps. We need to improve here to handle user sessions better but again let's not switch to the sledgehammer without having even tried. Restarting the whole system is a pretty pragmatic solution for the problem, you have to restart to use a new kernel as well anyway. There KSplice among others. Cheers, -- Guido -- 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/20140912120334.ga30...@bogon.m.sigxcpu.org
Re: PackageKit cleanup: Do you use these functions?
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
Re: PackageKit cleanup: Do you use these functions?
On Thu, 11 Sep 2014, Ansgar Burchardt wrote: Well, online updates do break software from time to time on my system. I’ve had to do unattended updates of our old Kubuntu desktop at work at shutdown time as well, due to breakage involved in upgrading them while being in use (especially the desktop software, most noteworthy Mozilla ware). Sometimes, rebooting (or, at least, logging out then in again) after upgrades that touch “desktop” components is better. Funnily enough, this isn’t so much true for server systems, where we just restart the dæmons affected, and occasionally want a new kernel if even that. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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/alpine.deb.2.11.140912150.7...@tglase.lan.tarent.de
Re: PackageKit cleanup: Do you use these functions?
2014-09-12 15:35 GMT+02:00 Thorsten Glaser t.gla...@tarent.de: On Thu, 11 Sep 2014, Ansgar Burchardt wrote: Well, online updates do break software from time to time on my system. I’ve had to do unattended updates of our old Kubuntu desktop at work at shutdown time as well, due to breakage involved in upgrading them while being in use (especially the desktop software, most noteworthy Mozilla ware). Sometimes, rebooting (or, at least, logging out then in again) after upgrades that touch “desktop” components is better. Funnily enough, this isn’t so much true for server systems, where we just restart the dæmons affected, and occasionally want a new kernel if even that. I fully agree with that, and Simons analysis. I will talk to the relevant people again, maybe we can get offline-updates happen on shutdown afterall... Cheers, Matthias -- 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/CAKNHny-be2U1X3yL_XL2edODdhf0VfsOh==tzwp5ko0tfup...@mail.gmail.com
Re: PackageKit cleanup: Do you use these functions?
On 12/09/14 14:29, Simon McVittie wrote: 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 if given the choice between upstreams spending N hours on implementing re-exec so their security updates are less disruptive, or spending N hours on security hardening / defensive programming so their security updates are less frequent or less urgent, I'd prefer the latter :-) 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/5412fb19.9070...@debian.org
Re: PackageKit cleanup: Do you use these functions?
Matthias wrote: PackageKit also has support for systemd-based offline-updates for a while now, which downloads updates while the system is running, and installs them in a special mode when the system is rebooting. This should ensure that no breakage happens when running applications are replaced with new versions. This is, however, a completely optional feature, and updates of the system while it is running are still possible with PK. GNOME (and especially GNOME-Software) seems to make more use of offline-updates, so we need to think about supporting it in Debian (main issue is debconf questions, which don't work well during offline-updates). I am not going to push that for Jessie, since it will require some precautions in Apt/the PK aptcc backend. But if you want, you can try it already. (Note that I want to keep this desktop-only, since on servers it does not make that much sense (esp. in case an error happens and the system doesn't recover correctly, which might happen until we have btrfs, which is upstream's plan)). Please push back hard against this - the offline-updates feature is a joke. Let's not try to emulate the worst bits of Windows any more please. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- 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/e1xs4rx-0008ts...@mail.einval.com
Re: PackageKit cleanup: Do you use these functions?
On 09/11/2014 15:30, Steve McIntyre wrote: Matthias wrote: PackageKit also has support for systemd-based offline-updates for a while now, which downloads updates while the system is running, and installs them in a special mode when the system is rebooting. This should ensure that no breakage happens when running applications are replaced with new versions. This is, however, a completely optional feature, and updates of the system while it is running are still possible with PK. GNOME (and especially GNOME-Software) seems to make more use of offline-updates, so we need to think about supporting it in Debian (main issue is debconf questions, which don't work well during offline-updates). I am not going to push that for Jessie, since it will require some precautions in Apt/the PK aptcc backend. But if you want, you can try it already. (Note that I want to keep this desktop-only, since on servers it does not make that much sense (esp. in case an error happens and the system doesn't recover correctly, which might happen until we have btrfs, which is upstream's plan)). Please push back hard against this - the offline-updates feature is a joke. Let's not try to emulate the worst bits of Windows any more please. Well, online updates do break software from time to time on my system. For system services they usually work fine as they can be restarted by the upgrade process, however user applications break... I think it's not realistic to expect upstreams to support online updates for every application. Once you have plugins or external data, it's hard to keep working properly after an upgrade. And at least I would prefer offline updates over my web browser crashing or shell completion breaking (until re-exec of the shell to be compatible with plugins). Ansgar -- 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/5411a64f.3080...@debian.org
Re: PackageKit cleanup: Do you use these functions?
In data giovedì 11 settembre 2014 15:40:31, Ansgar Burchardt ha scritto: Well, online updates do break software from time to time on my system. For system services they usually work fine as they can be restarted by the upgrade process, however user applications break... But I normally don't restart for weeks. That would make a reboot an extremely long process. Perhaps we should just change dpkg to have a flag that prevents upgrade if the process is running, and that shows some warning that tells to restart software X to avoid problems. I suppose package maintainers should be aware if their package can be upgraded while running or not. -- Salvo Tomaselli Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno. -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/1601319.n2WZFRHcOx@hal9000
Re: PackageKit cleanup: Do you use these functions?
2014-09-11 16:33 GMT+02:00 Salvo Tomaselli tipos...@tiscali.it: In data giovedì 11 settembre 2014 15:40:31, Ansgar Burchardt ha scritto: Well, online updates do break software from time to time on my system. For system services they usually work fine as they can be restarted by the upgrade process, however user applications break... But I normally don't restart for weeks. That would make a reboot an extremely long process. That's why the offline-upgrade procedure is an optional thing (and as an option, I see no problems in making it work well). Unexperienced users will get an update-on-reboot, and others can update the way they want. Perhaps we should just change dpkg to have a flag that prevents upgrade if the process is running, and that shows some warning that tells to restart software X to avoid problems. We have that in PackageKit, but I think it wasn't working well and has been removed (I need to check that). 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/CAKNHny-0ybcmo=-Qm�xgq_F=t3if=sxOgat=JoE=hbcju...@mail.gmail.com
Re: PackageKit cleanup: Do you use these functions?
Ansgar wrote: On 09/11/2014 15:30, Steve McIntyre wrote: Please push back hard against this - the offline-updates feature is a joke. Let's not try to emulate the worst bits of Windows any more please. Well, online updates do break software from time to time on my system. For system services they usually work fine as they can be restarted by the upgrade process, however user applications break... I think it's not realistic to expect upstreams to support online updates for every application. Once you have plugins or external data, it's hard to keep working properly after an upgrade. And at least I would prefer offline updates over my web browser crashing or shell completion breaking (until re-exec of the shell to be compatible with plugins). I would much prefer to not have to reboot the entire system and lose all state for the sake of a couple of userland application updates. If things don't work, file bugs. If the latest shiny desktop stuff can't cope with re-exec etc. well, then I'm glad to not be using it. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- 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/e1xs5dw-0001og...@mail.einval.com
Re: PackageKit cleanup: Do you use these functions?
Hi, And at least I would prefer offline updates over my web browser crashing or shell completion breaking (until re-exec of the shell to be compatible with plugins). I would much prefer to not have to reboot the entire system and lose all state for the sake of a couple of userland application updates. If things don't work, file bugs. If the latest shiny desktop stuff can't cope with re-exec etc. well, then I'm glad to not be using it. :-/ Then just not use this feature, and do your updates as you always did. It's entirely optional, after all. Kind regards Ralf -- 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/5412085c.10...@ralfj.de
Re: PackageKit cleanup: Do you use these functions?
On Thu, Sep 11, 2014 at 10:38:52PM +0200, Ralf Jung wrote: And at least I would prefer offline updates over my web browser crashing or shell completion breaking (until re-exec of the shell to be compatible with plugins). I would much prefer to not have to reboot the entire system and lose all state for the sake of a couple of userland application updates. If things don't work, file bugs. If the latest shiny desktop stuff can't cope with re-exec etc. well, then I'm glad to not be using it. :-/ Then just not use this feature, and do your updates as you always did. It's entirely optional, after all. This argument is either naive or disingenuous. Yes, it's an optional feature; it's also a feature that Matthias himself has said he would like unexperienced users to use. The only way that it's going to be available to unexperienced users is if it's /the default/. And if it's used by default, authors are going to blithely carry on implementing their software in a way that works badly when doing online upgrades, because everyone has agreed that this is acceptable - even Debian is doing it, and nobody cares more about upgrades that Debian! I understand that software (especially desktop software) not coping with online updates is an existing problem. The question is whether we - collectively - think moving to offline updates is an acceptable way to address this problem. And the time to raise that question is now, /before/ it becomes an entrenched assumption and leaves our users with no choice but to use it because their desktops become unusably broken if you apply package updates while they're running. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: PackageKit cleanup: Do you use these functions?
El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp matth...@tenstral.net escribió: Hello! (This is just a quick heads-up for the PackageKit-using people in Debian, so if you don't use PK, you can skip this mail.) We are currently cleaning up PackageKit[1] upstream, which means some functionality will soon no longer be available anymore. Short-term (= with one of the next uploads to Debian), I will remove the Smart backend from Debian, to use PackageKit with the Smart package-manager. This backend has also been removed upstream. So if you use/want to use PK with that backend, act now and implement the necessary bits upstream! The backend is currently broken in Debian, and carrying it around does not make much sense. The other long-term removed features include: * Transaction hooks (scripts to run after and before Pk transactions) * Support for plugins * .desktop file database and package-list caches * maybe the debug-info installer as well, although that's in discussion So, if you use one of these things, it would be good to think about a replacement, or give feedback upstream to keep these features. Depending on the state of PackageKit's reverse dependencies and other factors (use of the features described above by users), I will include the next release of PackageKit (1.0) which has the cleanup done in Jessie or not (currently, keeping 0.9.x seems more likely) PackageKit also has support for systemd-based offline-updates for a while now, which downloads updates while the system is running, and installs them in a special mode when the system is rebooting. This should ensure that no breakage happens when running applications are replaced with new versions. This is, however, a completely optional feature, and updates of the system while it is running are still possible with PK. 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). 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? Thanks for the communication, -- Cameron Norman
Re: PackageKit cleanup: Do you use these functions?
On 11/09/14 14:50, Ansgar Burchardt wrote: I think it's not realistic to expect upstreams to support online updates for every application. Once you have plugins or external data, it's hard to keep working properly after an upgrade. Surely the solution to this is to restart the affected application rather than rebooting the whole computer? Roger -- 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/inn9eb-fq8@silverstone.rilynn.me.uk
