Bug 830181

As from F18, we're doing this: http://freedesktop.org/wiki/Software/systemd/SystemUpdates -- see https://fedoraproject.org/wiki/Features/OfflineSystemUpdates for details.

Richard, that wiki page talks about "system updates", and you're right, that should be solved - in GNOME.

1. What about application updates in GNOME, how will they be handled? Can I enable auto-update of application updates? Will they be installed on the running system (F17 behavior) or after restart (offline-updates)?

2. What about system updates in KDE/XFCE/elsewhere? Is this solved as well? Or the situation is completely the same as in F17 - users can enable auto-update in their settings and that can possibly break their system afterwards? In that case this bug wouldn't be fixed.

3. Can you we - the QA - learn what's included in system updates and what's included in application updates? We need to know which package is considered which update type, so that we can check everything works as expected.

Thanks.

(In reply to comment #2)
> 3. Can you we - the QA - learn what's included in system updates and what's
     ^^^^^^^^^^
     How can we

(In reply to comment #2)
> 1. What about application updates in GNOME, how will they be handled? Can I
> enable auto-update of application updates? Will they be installed on the
> running system (F17 behavior) or after restart (offline-updates)?

You can do either at the moment. The plan for F18 is to do all automatic updates offline, and anything user-triggered live, so to speak.

> 2. What about system updates in KDE/XFCE/elsewhere? Is this solved as well?

No clue, I'm a GNOME developer. I imagine KDE users are using apper which I think does does live-updating, although I'm not sure. XFCE/others have to run either apper or gnome-packagekit as they've got nothing native.

> Or the situation is completely the same as in F17 - users can enable
> auto-update in their settings and that can possibly break their system
> afterwards? In that case this bug wouldn't be fixed.

No, if the user doesn't disable auto-updates then the updates are downloaded in the session and updated on next boot if they select "Restart and install updates".

> 3. Can you we - the QA - learn what's included in system updates and what's
> included in application updates? We need to know which package is considered
> which update type, so that we can check everything works as expected.

If you want to force an OS update, you can use "pkcon --only-download update powertop" and then use the "Restart and install updates" when that's complete.

We've not put the time in yet to automatically work out what updates should be done offline or live yet. That's something that would probably wake the trolls on devel@fedora, so it's not something I'm looking forward to.

Richard.

Dropping the block on F18Alpha, as it shows up as a proposed blocker even though it's closed.

If we are worried about the situation wrt KDE, Xfce and LXDE, we should evaluate each spin and file new bugs against the relevant components as appropriate. I believe KDE uses apper, which does live updates, but I don't know offhand if it has a 'silent auto-update' option. I believe the Xfce and LXDE spins use yumex; again, not sure what the auto-update options are there. Kamil, do you want to take charge of checking this out with the other supported desktops? Thanks!

(In reply to comment #5)
> Kamil, do you want to take charge of checking this out with the other
> supported desktops? Thanks!

Yes, I'll do that once we have some test compose.

Checking with F17 ought to be fine, really, I don't think any desktop has changed its package manager between 17 and 18.

I checked all DEs. GNOME is fine, it no longer offers the option to auto-update, instead it uses offline-updates. XFCE and LXDE doesn't use gnome-packagekit at all and yumex doesn't seem to support auto-update.

The only problem is in KDE, where auto-update is disabled by default, but it is still available (see screenshot). The user can change this setting and then end up with a broken system one day. Reassigning to apper (as I understand it is the correct component in KDE).

Proposing as F18 Final NTH.

Created attachment 612822 [details]
auto-update in apper

If I understand correctly, you're proposing that the ability to auto-install  anything in apper be removed? (or if something else, please do explain further)

OK, read over bug  #755335 , the issue at hand seems to be that when auto-install feature is enabled, shutting down during updates installing =>  fail.  no argument there.

I'm not sure that warrants too drastic an action for something that's clearly user-error, but will think about it some more.

(In reply to comment #10)
> If I understand correctly, you're proposing that the ability to auto-install
> anything in apper be removed? (or if something else, please do explain
> further)

Yes, I believe the whole drop-down list should be removed until we have a safe way to do auto-updating. That means the system should refuse to shut down if auto-update process is running.

(In reply to comment #11)
> I'm not sure that warrants too drastic an action for something that's
> clearly user-error, but will think about it some more.

It's not really a user-error. User doesn't know about auto-updating taking place, it's happening in the background, as requested. Does KDE have some highly visible pop-up to alert the user that the system is being updated and it shouldn't be shut down until it is finished? If not, there is no way how the user could know that he's not supposed to shut down the system (that was the case for GNOME 3.4).

There is a notification when updates start and are underway, but it probably doesn't count as "highly visibible"

I'm pretty sure apper will set an inhibition on shutdown/reboot when an update is underway; doesn't prevent you from pulling the plug manually of course :)

I just tested with F18 Alpha RC3 KDE. It shows exactly the same symptoms as described in bug 755335. I asked apper to auto-install all updates, set hourly check and waited with 'ps aux | grep yum' for packagekit to begin installation. Once it did (a system popup also appeared), I waited until it applied deltarpms and started real installation. Then I powered off the machine correctly using the menus. There was no warning, no inhibitor.

After reboot, 'yum history' reports broken update and 'yum check' reports 25 errors - duplicate packages.

Maybe apper inhibitor no longer works?

acked, getting this cleared up with dantti (the apper's author)

Adjusting summary to describe the real issue.

That said, this doesn't look like a serious issue to me. For one, automatic updates are not enabled by default (and for manual updates, you hopefully won't shutdown your machine while running them), and secondly, the messed-up state can usually be fixed using yum-complete-transaction or yum history redo.

kk: it's true that it's not the default state, and so we're much less worried than we were about the GNOME incarnation. your second statement is likely untrue though, there's all sorts of ways a yum/rpm process that's killed without warning can go wrong which can't be fixed with those commands.

Discussed on irc at length over the last couple of days with ltinkl and dannti (with here-say comments from hughsie), and came to the conclusion that packagekitd either is or *should be* the best place to handle systemd inhibits when packagekitd is processing stuff.  

(that should naturally handle all PK-frontends, including pkcon too).

Please correct me if my characterization of discussions or facts is incorrect.

reassigning => PackageKit

Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . We agreed we're wary of taking major PackageKit changes this late to fix a bug which isn't critical (as noted above it's different from the F17 GNOME case because auto-update is not the default config), so this is rejected as NTH - if this is going to be done we'd like it to be done in the normal course of development, not as a last minute fix.