Move KDE software updates notifications to upstream infrastructure
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.
- 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.
Should stay the same
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.
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.
Set user benefit
You can add different relations here, for example duplicate features, obs projects, urls...
To embedd an image you can simply upload it to paste.opensuse.org and add a relation to its raw url.
Set release notes
- 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
Last change: 2 months ago