Home_greyopenFATE - openSUSE feature tracking > #305394
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Move KDE software updates notifications to upstream infrastructure

Feature state

openSUSE Distribution


As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet.

It already implements various aspects of kupdateapplet:

  • notifications (knotify) using a kded service (which takes care of refreshing too)
  • single update selection (kpackagekit gui)
  • uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code.


kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here.

Open Issues:

  • tray notification: may require implementing a plasma tray icon
  • SUSE specific code (smolt, registration, hardware search)
    • Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service.

User experience

Should stay the same


  • PackageKit
  • libpackagekit-qt

Contingency Plan

In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit.
Otherwise, we can stay with kupdateapplet as a fallback.

User benefit:

Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it).

This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client.

Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require).

This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code.

Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions.



  • new patches should be notified by knotify
  • user should be able to see update availability
  • user should be able to see detailed update information, as well as selecting individual updates
  • user should get informed if the update repositories configuration has a problem
  • user should be informed of (available) drivers for plugged hardware


icons/user_comment.png F. L. wrote: (8 years ago)

Looks like Duncan is in favor of this. Stano?

If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade.

icons/user_comment.png D. M. wrote: (8 years ago)

I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important.

Feedback from the KDE team about upstream KDE 4.3 would also be useful.

icons/user_comment.png L. L. wrote: (7 years ago)

Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me.

I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3.

icons/user_comment.png M. S. wrote: (7 years ago)

Is the proposal not just like the status with Gnome (in 11.2)?

If so I would not recomend that (way of) change:

I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software).

icons/user_comment.png F. L. wrote: (7 years ago)

Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported.


The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing.

icons/user_comment.png M. S. wrote: (7 years ago)

Sorry if my first comment seems to be so contra.

I have only voted neutral and am not sure.

If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?).

But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?):

for example (some of the first results of "update" and "applet" - some of 300):






icons/user_comment.png P. P. wrote: (7 years ago)

I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down.

icons/user_comment.png D. M. wrote: (6 years ago)

If you have problems, please report concrete bugs.

icons/user_comment.png S. P. wrote: (6 years ago)

Seems like this is done for 11.4

icons/user_comment.png F. M. wrote: (6 years ago)


icons/user_comment.png M. B. wrote: (6 years ago)

I have openSUSE 11.4RC1 and the first time I used KpackageKit to install an RPM pakage - it chashed! see https://bugs.kde.org/show_bug.cgi?id=266448

icons/user_comment.png R. L. wrote: (6 years ago)

Kpackagekit is not only problematic and inefficient, it is redundant. Remove from 12.1.

icons/user_comment.png J. P. wrote: (6 years ago)

If we want to have Bretzn and Appstream -> cross-distro app installers, packagekit is crucial. The GUI might be replaced by Bretzn, or augmented - but the underlying tech will have to stay in any case.

icons/user_comment.png W. S. wrote: (5 years ago)

'Done' for 12.1 with Apper, modulo bugs...

Last change: 2 months ago
Score: 39
  • Negative: 12
  • Neutral: 5
  • Positive: 51
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint