Talk:Features/OfflineSystemUpdates

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(answer some more questions)
(switch to a threated view so one can respond and see which questions are addressed)
Line 1: Line 1:
--[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC) :
+
* package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode. --[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC)
* package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode.
+
** No, why ? The updated package is installed in just the same way. The only difference with offline mode is that there is a reboot before and after the installation of the new packages. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
* can we get examples of packages that don't update through the regular process and reasons why not?
+
* how do people update problematic packages from terminal/non-gnome envs?
+
* is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons?
+
* "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application?
+
  
--[[User:Jnovy|Jnovy]] 14:38, 15 June 2012 (UTC) :
 
* shouldn't there exist an API to even allow rpm/yum to schedule an offline update?
 
* if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level?
 
* use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.
 
  
----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
+
* can we get examples of packages that don't update through the regular process and reasons why not? --[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC)
* Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?
+
* How does the differentiation between 'OS components' and applications work?
+
* We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?
+
* What about reboot vs. log out? We only have reboot available in bodhi.
+
* The checkbox in bodhi reads "''Suggest'' Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or ''only'' on reboot?
+
* How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information?
+
* What infrastructure is needed on the server side to provide this information? How is it transported?
+
* What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?
+
* Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?
+
* Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS.
+
* What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads?
+
* Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).
+
* What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?
+
  
----
+
* how do people update problematic packages from terminal/non-gnome envs? --[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC)
* From https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates : "If the app is running it would ask if it is ok to restart the app for you after it installs the update."  How is that supposed to work?
+
** Not sure I understand these questions. We generally don't ship packages that 'don't update'. The gist of this feature is that by doing the update in the middle of your running system, you end up in a subtly inconsistent state. E.g. if you update a library, all the running applications will still use the old version of the library, while newly started applications will use the new one. Your system will limp along most of the time. Except for when it breaks in mysterious and hard-to-understand ways. The goal of this feature is to eliminate the risk of such breakages. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
* If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
+
** You can either use "pkcon update foo --only-download" or use yum to download the packages to a cache and then do /usr/libexec/pk-trigger/offline-update. It's also expected than Daniel will add support for this to Apper, for KDE support. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
** Related to that, what changes _not_ caused by the update attempt can happen during the bootup and will be incorrectly reverted?  (e.g. AD machine account passwords) - in general, the reverts do sound risky. The first reboot makes it a little better, but still worrying.
+
* Bikeshedding - Why isn't the /system-update file in /etc?
+
--[[User:Mitr|Mitr]] 18:13, 15 June 2012 (UTC)
+
  
----
 
Answering some of these questions:
 
* package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode.
 
  
No, why ? The updated package is installed in just the same way. The only difference with offline mode is that there is a reboot before and after the installation of the new packages.
+
* is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons? --[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC)
 +
** Not a serious question, is it ? In case it is: my answer would be 'no'. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
  
* can we get examples of packages that don't update through the regular process and reasons why not?
 
* how do people update problematic packages from terminal/non-gnome envs?
 
  
Not sure I understand these questions. We generally don't ship packages that 'don't update'. The gist of this feature is that by doing the update in the middle of your running system, you end up in a subtly inconsistent state. E.g. if you update a library, all the running applications will still use the old version of the library, while newly started applications will use the new one. Your system will limp along most of the time. Except for when it breaks in mysterious and hard-to-understand ways. The goal of this feature is to eliminate the risk of such breakages.
+
* "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application? --[[User:Akozumpl|Akozumpl]] 14:08, 15 June 2012 (UTC)
 +
** I've now put some information about the heuristics for 'OS component' vs application in the feature page. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
  
* is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons?
 
  
Not a serious question, is it ? In case it is: my answer would be 'no'.
+
----
  
* "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application?
 
* How does the differentiation between 'OS components' and applications work?
 
  
I've now put some information about the heuristics for 'OS component' vs application in the feature page.
+
* shouldn't there exist an API to even allow rpm/yum to schedule an offline update? --[[User:Jnovy|Jnovy]] 14:38, 15 June 2012 (UTC)
 +
* if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level? --[[User:Jnovy|Jnovy]] 14:38, 15 June 2012 (UTC)
 +
** The API is at the systemd level, can't get much lower than that. If rpm/yum want to grow an 'offline update' mode, they can. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
 +
** There's a simple API for this, see https://gitorious.org/packagekit/packagekit/blobs/master/contrib/systemd-updates/README.txt for details. I think it's logically on level higher than yum, tho. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* shouldn't there exist an API to even allow rpm/yum to schedule an offline update?
 
* if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level?
 
  
The API is at the systemd level, can't get much lower than that. If rpm/yum want to grow an 'offline update' mode, they can.
+
* use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates. --[[User:Jnovy|Jnovy]] 14:38, 15 June 2012 (UTC)
 +
** PackageKit is doing that today. See CheckSharedLibrariesInUse and UpdateCheckProcesses in /etc/PackageKit/PackageKit.conf --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
 +
** I don't think that's in the remit of rpm. rpm certainly doesn't want to be doing this process parsing stuff. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.
 
  
PackageKit is doing that today. See CheckSharedLibrariesInUse and UpdateCheckProcesses in /etc/PackageKit/PackageKit.conf
+
----
  
* Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?
 
* Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).
 
  
2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system.
+
* Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
And we want to reboot after installing the updates to ensure that all the newly updates components are actually used.
+
** 2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system. And we want to reboot after installing the updates to ensure that all the newly updates components are actually used. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
 +
** The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?
 
* What about reboot vs. log out? We only have reboot available in bodhi.
 
* The checkbox in bodhi reads "''Suggest'' Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or ''only'' on reboot?
 
* How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information?
 
* What infrastructure is needed on the server side to provide this information? How is it transported?
 
  
This feature is not about fine-grained control of when to reboot / logout like these questions seem to assume. We want to broadly say 'OS updates are done offline'. If you know what you are doing and think you don't need to reboot, you can (and most likely already are) just use the commandline. 
+
* Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again). ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** I discussed this on the systemd mailing list, here's the archive: http://lists.freedesktop.org/archives/systemd-devel/2011.../003190.html , TLDR, basically Lennart wants a known-good environment to do the updates in, rather than having dozens of random processes running. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?
 
  
I can't say in detail how the cleaning of the downloaded packages will be organized, but the offline update cache is only put in place when you actually trigger it by hitting 'Restart and install updates' in the menu.
+
* How does the differentiation between 'OS components' and applications work? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** I've now put some information about the heuristics for 'OS component' vs application in the feature page. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
  
* Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?
 
  
See my answer above - there are no 'reboot requests' per se. PackageKit just uses heuristics to decide how to treat available updates.
+
* We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** We want to do the majority of updates offline, rather than in the running session. It also makes sense from a snapshotting point of view to have as little other stuff running as possible. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS.
 
  
Yes, it does have a way. And in fact, gpk-application has had a 'Check for updates when on mobile broadband' option for a long time.
+
* What about reboot vs. log out? We only have reboot available in bodhi. ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** At the moment, the new updater application doesn't use this data from bodhi at all as most updates are going to be done offline. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads?
 
  
Again, not sure if this is a serious question - worst case, the same thing will happen that happens today when you shutdown while yum is downloading updates.
+
* The checkbox in bodhi reads "''Suggest'' Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or ''only'' on reboot? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
  
* What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?
+
* How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
  
I don't know this for a fact, but I would assume that we don't pass 'break my system' options like --skip-broken when the goal of the feature is to
+
* What infrastructure is needed on the server side to provide this information? How is it transported? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
'''reduce''' the potential for updates-induced breakage...
+
** This feature is not about fine-grained control of when to reboot / logout like these questions seem to assume. We want to broadly say 'OS updates are done offline'. If you know what you are doing and think you don't need to reboot, you can (and most likely already are) just use the commandline. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
--[[User:Mclasen|mclasen]] 00:15, 16 June 2012 (UTC)
+
  
  
----
+
* What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
Answering some more of these questions:
+
** I can't say in detail how the cleaning of the downloaded packages will be organized, but the offline update cache is only put in place when you actually trigger it by hitting 'Restart and install updates' in the menu.  --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
 +
** Yes, a PackageKit plugin clears the prepared-update flag if the user does any update operation manually. It's only reset when the next idle GetUpdates is done, which I think is going to be once a day. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* how do people update problematic packages from terminal/non-gnome envs?
+
* Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** See my answer above - there are no 'reboot requests' per se. PackageKit just uses heuristics to decide how to treat available updates. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
 +
** YUM could implement the OfflineOSUpdates thing if it wants, but it was done in PK so to work for all the distros, not just Fedora. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
You can either use "pkcon update foo --only-download" or use yum to download the packages to a cache and then do /usr/libexec/pk-trigger/offline-update
 
  
It's also expected than Daniel will add support for this to Apper, for KDE support.
+
* Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS  installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS. ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** Yes, it does have a way. And in fact, gpk-application has had a 'Check for updates when on mobile broadband' option for a long time. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
  
* shouldn't there exist an API to even allow rpm/yum to schedule an offline update?
 
  
There's a simple API for this, see https://gitorious.org/packagekit/packagekit/blobs/master/contrib/systemd-updates/README.txt for details. I think it's logically on level higher than yum, tho.
+
* What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** Again, not sure if this is a serious question - worst case, the same thing will happen that happens today when you shutdown while yum is downloading updates. --[[User:Mclasen|mclasen]] 00:19, 16 June 2012 (UTC)
  
* use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.
 
  
I don't think that's in the remit of rpm. rpm certainly doesn't want to be doing this process parsing stuff.
+
* What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken? ----[[User:Cwickert|Cwickert]] 18:06, 15 June 2012 (UTC)
 +
** I don't know this for a fact, but I would assume that we don't pass 'break my system' options like --skip-broken when the goal of the feature is to '''reduce''' the potential for updates-induced breakage... --[[User:Mclasen|mclasen]] 00:15, 16 June 2012 (UTC)
 +
** Updates will fail to be applied, and the prepared-update file will be removed, with an error log written than can be read from the session. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?
 
  
The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds.
+
----
  
* We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?
 
  
We want to do the majority of updates offline, rather than in the running session. It also makes sense from a snapshotting point of view to have as little other stuff running as possible.
+
* From https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates : "If the app is running it would ask if it is ok to restart the app for you after it installs the update."  How is that supposed to work? --[[User:Mitr|Mitr]] 18:13, 15 June 2012 (UTC)
 +
** This isn't part of this feature -- it would require more work to other parts of our stack first. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
* What about reboot vs. log out? We only have reboot available in bodhi.
 
 
At the moment, the new updater appliction doesn't use this data from bodhi at all as most updates are going to be done offline.
 
 
* What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?
 
 
Yes, a PackageKit plugin clears the prepared-update flag if the user does any update operation manually. It's only reset when the next idle GetUpdates is done, which I think is going to be once a day.
 
 
* Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?
 
 
YUM could implement the OfflineOSUpdates thing if it wants, but it was done in PK so to work for all the distros, not just Fedora.
 
 
* Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).
 
 
I discussed this on the systemd mailing list, here's the archive: http://lists.freedesktop.org/archives/systemd-devel/2011.../003190.html , TLDR, basically Lennart wants a known-good environment to do the updates in, rather than having dozens of random processes running.
 
 
* What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?
 
 
Updates will fail to be applied, and the prepared-update file will be removed, with an error log written than can be read from the session.
 
 
* From https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates : "If the app is running it would ask if it is ok to restart the app for you after it installs the update."  How is that supposed to work?
 
 
This isn't part of this feature -- it would require more work to other parts of our stack first.
 
  
 
* If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
 
* If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
 +
* Related to that, what changes _not_ caused by the update attempt can happen during the bootup and will be incorrectly reverted?  (e.g. AD machine account passwords) - in general, the reverts do sound risky.  The first reboot makes it a little better, but still worrying. --[[User:Mitr|Mitr]] 18:13, 15 June 2012 (UTC)
 +
** The btrfs snapshot isn't implemented in this feature, so we've not looked at all the details yet. We can't realistically work on the snapshotting until Fedora uses btrfs for / by default. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
  
The btrfs snapshot isn't implemented in this feature, so we've not looked at all the details yet. We can't realistically work on the snapshotting until Fedora uses btrfs for / by default.
 
 
* Bikeshedding - Why isn't the /system-update file in /etc?
 
 
Lennart wanted it in /, just like the other flags like the selinux relabel flag. IIRC, putting it in root makes the generator easier to write as we're sure the directory is mounted.
 
  
--[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)
+
* Bikeshedding - Why isn't the /system-update file in /etc? --[[User:Mitr|Mitr]] 18:13, 15 June 2012 (UTC)
 +
** Lennart wanted it in /, just like the other flags like the selinux relabel flag. IIRC, putting it in root makes the generator easier to write as we're sure the directory is mounted. --[[User:Rhughes|rhughes]] 07:15, 16 June 2012 (UTC)

Revision as of 10:44, 18 June 2012

  • package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode. --Akozumpl 14:08, 15 June 2012 (UTC)
    • No, why ? The updated package is installed in just the same way. The only difference with offline mode is that there is a reboot before and after the installation of the new packages. --mclasen 00:19, 16 June 2012 (UTC)


  • can we get examples of packages that don't update through the regular process and reasons why not? --Akozumpl 14:08, 15 June 2012 (UTC)
  • how do people update problematic packages from terminal/non-gnome envs? --Akozumpl 14:08, 15 June 2012 (UTC)
    • Not sure I understand these questions. We generally don't ship packages that 'don't update'. The gist of this feature is that by doing the update in the middle of your running system, you end up in a subtly inconsistent state. E.g. if you update a library, all the running applications will still use the old version of the library, while newly started applications will use the new one. Your system will limp along most of the time. Except for when it breaks in mysterious and hard-to-understand ways. The goal of this feature is to eliminate the risk of such breakages. --mclasen 00:19, 16 June 2012 (UTC)
    • You can either use "pkcon update foo --only-download" or use yum to download the packages to a cache and then do /usr/libexec/pk-trigger/offline-update. It's also expected than Daniel will add support for this to Apper, for KDE support. --rhughes 07:15, 16 June 2012 (UTC)


  • is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons? --Akozumpl 14:08, 15 June 2012 (UTC)
    • Not a serious question, is it ? In case it is: my answer would be 'no'. --mclasen 00:19, 16 June 2012 (UTC)


  • "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application? --Akozumpl 14:08, 15 June 2012 (UTC)
    • I've now put some information about the heuristics for 'OS component' vs application in the feature page. --mclasen 00:19, 16 June 2012 (UTC)




  • shouldn't there exist an API to even allow rpm/yum to schedule an offline update? --Jnovy 14:38, 15 June 2012 (UTC)
  • if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level? --Jnovy 14:38, 15 June 2012 (UTC)


  • use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates. --Jnovy 14:38, 15 June 2012 (UTC)
    • PackageKit is doing that today. See CheckSharedLibrariesInUse and UpdateCheckProcesses in /etc/PackageKit/PackageKit.conf --mclasen 00:19, 16 June 2012 (UTC)
    • I don't think that's in the remit of rpm. rpm certainly doesn't want to be doing this process parsing stuff. --rhughes 07:15, 16 June 2012 (UTC)




  • Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target? ----Cwickert 18:06, 15 June 2012 (UTC)
    • 2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system. And we want to reboot after installing the updates to ensure that all the newly updates components are actually used. --mclasen 00:19, 16 June 2012 (UTC)
    • The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds. --rhughes 07:15, 16 June 2012 (UTC)


  • Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again). ----Cwickert 18:06, 15 June 2012 (UTC)


  • How does the differentiation between 'OS components' and applications work? ----Cwickert 18:06, 15 June 2012 (UTC)
    • I've now put some information about the heuristics for 'OS component' vs application in the feature page. --mclasen 00:19, 16 June 2012 (UTC)


  • We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future? ----Cwickert 18:06, 15 June 2012 (UTC)
    • We want to do the majority of updates offline, rather than in the running session. It also makes sense from a snapshotting point of view to have as little other stuff running as possible. --rhughes 07:15, 16 June 2012 (UTC)


  • What about reboot vs. log out? We only have reboot available in bodhi. ----Cwickert 18:06, 15 June 2012 (UTC)
    • At the moment, the new updater application doesn't use this data from bodhi at all as most updates are going to be done offline. --rhughes 07:15, 16 June 2012 (UTC)


  • The checkbox in bodhi reads "Suggest Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or only on reboot? ----Cwickert 18:06, 15 June 2012 (UTC)
  • How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information? ----Cwickert 18:06, 15 June 2012 (UTC)
  • What infrastructure is needed on the server side to provide this information? How is it transported? ----Cwickert 18:06, 15 June 2012 (UTC)
    • This feature is not about fine-grained control of when to reboot / logout like these questions seem to assume. We want to broadly say 'OS updates are done offline'. If you know what you are doing and think you don't need to reboot, you can (and most likely already are) just use the commandline. --mclasen 00:19, 16 June 2012 (UTC)


  • What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned? ----Cwickert 18:06, 15 June 2012 (UTC)
    • I can't say in detail how the cleaning of the downloaded packages will be organized, but the offline update cache is only put in place when you actually trigger it by hitting 'Restart and install updates' in the menu. --mclasen 00:19, 16 June 2012 (UTC)
    • Yes, a PackageKit plugin clears the prepared-update flag if the user does any update operation manually. It's only reset when the next idle GetUpdates is done, which I think is going to be once a day. --rhughes 07:15, 16 June 2012 (UTC)
  • Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described? ----Cwickert 18:06, 15 June 2012 (UTC)
    • See my answer above - there are no 'reboot requests' per se. PackageKit just uses heuristics to decide how to treat available updates. --mclasen 00:19, 16 June 2012 (UTC)
    • YUM could implement the OfflineOSUpdates thing if it wants, but it was done in PK so to work for all the distros, not just Fedora. --rhughes 07:15, 16 June 2012 (UTC)


  • Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS. ----Cwickert 18:06, 15 June 2012 (UTC)
    • Yes, it does have a way. And in fact, gpk-application has had a 'Check for updates when on mobile broadband' option for a long time. --mclasen 00:19, 16 June 2012 (UTC)


  • What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads? ----Cwickert 18:06, 15 June 2012 (UTC)
    • Again, not sure if this is a serious question - worst case, the same thing will happen that happens today when you shutdown while yum is downloading updates. --mclasen 00:19, 16 June 2012 (UTC)


  • What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken? ----Cwickert 18:06, 15 June 2012 (UTC)
    • I don't know this for a fact, but I would assume that we don't pass 'break my system' options like --skip-broken when the goal of the feature is to reduce the potential for updates-induced breakage... --mclasen 00:15, 16 June 2012 (UTC)
    • Updates will fail to be applied, and the prepared-update file will be removed, with an error log written than can be read from the session. --rhughes 07:15, 16 June 2012 (UTC)





  • If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
  • Related to that, what changes _not_ caused by the update attempt can happen during the bootup and will be incorrectly reverted? (e.g. AD machine account passwords) - in general, the reverts do sound risky. The first reboot makes it a little better, but still worrying. --Mitr 18:13, 15 June 2012 (UTC)
    • The btrfs snapshot isn't implemented in this feature, so we've not looked at all the details yet. We can't realistically work on the snapshotting until Fedora uses btrfs for / by default. --rhughes 07:15, 16 June 2012 (UTC)


  • Bikeshedding - Why isn't the /system-update file in /etc? --Mitr 18:13, 15 June 2012 (UTC)
    • Lennart wanted it in /, just like the other flags like the selinux relabel flag. IIRC, putting it in root makes the generator easier to write as we're sure the directory is mounted. --rhughes 07:15, 16 June 2012 (UTC)