--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.
- 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?
--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.
Cwickert 18:06, 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?