I have never been able to get update details in Apper, as pictured in the image here:
http://paste.opensuse.org/view/simple/98694384
Regardless of which package or update.
Why is this?
See here: https://bugzilla.novell.com/show_bug.cgi?id=855993
In short: PackageKit’s ShutdownTimeout is set to 15 seconds by default on openSUSE, after that time it quits to not block YaST/zypper any more.
Therefore Apper cannot show the details any more after that timeout (before that, it should work fine).
You can raise this value in /etc/PackageKit/PackageKit.conf, or install “PackageKit-branding-upstream” to get the upstream default of 5 minutes.
But be prepared that PackageKit will then block YaST/zypper for that prolonged period.
I rarely use Yast/Zypper these days so an increase to default 300 seconds on /etc/PackageKit/PackageKit.conf works fine for me.
However, what if one decides to postpone the update for later (or one overlooks the update when it comes), one would need to “check for updates” again in order to get the update details. This is a flaw.
Yes, of course it is a flaw/bug.
But AFAICT nobody ever reported this upstream at KDE.
Maybe that’s just because of the default 5 minutes timeout, so most people don’t even notice it (and those that did, didn’t bother to report a bug yet… 
), or it is indeed an openSUSE specific bug, i.e. in PackageKit’s zypp backend.
I don’t know yet. Maybe somebody should check this on Kubuntu or some other distribution.
I used Apper for years, even kind of liked it, and only recently gave up on it and went to simply using zypper. The thing is that it did kind of annoy me that it would (mostly) not show the update details (it would on occasion). But given how often Apper gets bashed on these forums, I rather assumed that it was just another thing that didn’t work and would never be fixed. Like the setting for how often it should check for updates.
I already explained the reason for that, and gave a (kind of) workaround.
But given how often Apper gets bashed on these forums, I rather assumed that it was just another thing that didn’t work and would never be fixed. Like the setting for how often it should check for updates.
No, apper works fine otherwise.
The setting for how often it should check for updates works fine as well.
But it is checking for updates on every login as it doesn’t save anywhere when it did the last check.
The only other limitation I’m aware of is that it doesn’t allow to resolve conflicts.
If there is a conflict, you just get an error message.
Yes, thanks for the work-around. I’ll try that sometime in the future, probably when I update to 13.1. And as I said, I used it for years and was generally happy. It would be nice to be able to disable that initial check, or better yet, set a time for it, as my process is typically to check for updates when I am about to close my laptop down, and having packagekit doing its thing when I’m trying to get the all my normal apps loaded for the day slowed me down a bit.
But the thing that finally drove me to give up on it this time was the fact that it doesn’t honor locks placed on packages in yast. I run a custom kernel to support my alps touchpad, so I have the kernel packages locked. But whenever I updated using apper I always had to remember to deselect the kernel updates, or I would have had to spend a bunch of time getting it back on my custom kernel, with nvidia installed the hard way, etc. If there is a way to lock packages in apper, I never found it. I don’t have this problem using zypper up.
Yes, I agree completely.
Btw, I did find a bug report:
https://bugs.kde.org/show_bug.cgi?id=317838
And the “show details” issue has been reported upstream as well actually:
https://bugs.kde.org/show_bug.cgi?id=331068
But the thing that finally drove me to give up on it this time was the fact that it doesn’t honor locks placed on packages in yast. I run a custom kernel to support my alps touchpad, so I have the kernel packages locked. But whenever I updated using apper I always had to remember to deselect the kernel updates, or I would have had to spend a bunch of time getting it back on my custom kernel, with nvidia installed the hard way, etc. If there is a way to lock packages in apper, I never found it. I don’t have this problem using zypper up.
Apper (or rather PackageKit-backend-zypp) should respect Locks you add in YaST.
If not, this would be a bug in PackageKit’s zypp backend.
And it seems to work fine here.
But you have to lock the correspanding patches in YaST->Online Updates as well, as Apper/PackageKit would want to install them, circumventing the package lock.
I guess if you enter YaST->Online Updates, it would want to install the kernel update as well?
Well, I’ve never tried Yast Online Updates (until now). What comes up is an conflict resolution dialogue for two un-named suse updates, and one of the resolution options is “Do not forbid installation of” a kernel package. When I select “do not install” the offending package, it presents me with a couple of kernel updates, but unselected. It seems like the package lock is being honored. Maybe I misunderstood something that you said, or maybe this is exactly what you expected when you said “it would want to install the kernel update as well”. In any event, this is better than apper silently trying to sneak the updates onto my system.
Apper would just fail when it tries to install the update because of the conflict, it wouldn’t sneak anything onto your system.
And again, to prevent that, you would have to lock the patch itself (not the individual packages) in YaST->Online Updates, by right-clicking on it and selecting “Taboo - Never install” (on the left side, not in the package list on the right side).
Then Apper should not show it anymore.
And this is nothing Apper-specific as you should have noticed now, that’s just how libzypp (which is used by Yast, zypper, and PackageKit) handles patches.