Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
  • From: fate_noreply@xxxxxxx
  • Date: Fri, 12 Mar 2010 11:40:56 +0100 (CET)
  • Message-id: <feature-305394-33@xxxxxxxxxxxxxx>
Feature changed by: Lubos Lunak (llunak)
Feature #305394, revision 33
Title: Move KDE software updates notifications to upstream

openSUSE-11.2: Rejected by Christoph Thiel (cthiel1)
reject date: 2009-07-16 11:29:01
reject reason: out of resources for 11.2.
Requester: Important
Projectmanager: Important

openSUSE-11.3: Evaluation
Requester: Important

Requested by: Duncan Mac-Vicar (dmacvicar)
Partner organization:

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
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.

- kpackagekit author interview (url:
- kpackagekit screenshot (url:

Test Case:
* 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

Business case (Partner 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.

#1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20)
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.

#5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54)
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

+ #8: Lubos Lunak (llunak) (2010-03-12 11:40:52)
+ 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.

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages