Mailinglist Archive: opensuse-features (263 mails)

< Previous Next >
[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
Feature changed by: Roger Luedecke (Shadowolf7)
Feature #305394, revision 46
Title: Move KDE software updates notifications to upstream
infrastructure

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

openSUSE-11.3: Rejected by Sascha Peilicke (saschpe)
reject reason: 11.3 is out for a while, wasn't done
Priority
Requester: Important

openSUSE-11.4: Unconfirmed
Priority
Requester: Neutral

Requested by: Duncan Mac-Vicar (dmacvicar)
Product Manager: (Novell)
Product Manager: (Novell)
Project Manager: (Novell)
Engineering Manager: (Novell)
Technical Contact: (Novell)
Technical Contact: Stephan Binner (beineri)
Partner organization: openSUSE.org

Description:
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.
Scope
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
Dependencies
* 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.

Relations:
- kpackagekit author interview (url:
http://polishlinux.org/kde/kpackagekit-interview/)
- kpackagekit screenshot (url:
http://www.packagekit.org/img/kpk-update.png)

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):
openSUSE.org: 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.

Discussion:
#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
useful.

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

#9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15)
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).

#10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to
#9)
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.

#11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to
#10)
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):

http://forums.opensuse.org/get-help-here/applications/441112-updater-applet-giving-me-error.html

http://forums.opensuse.org/get-help-here/applications/440994-kupdater-applet-throwing-error.html

http://forums.opensuse.org/get-help-here/applications/440391-problem-updating.html

http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updater-app-question.html
...
 
 
 

#12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11)
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.

#15: Duncan Mac-Vicar (dmacvicar) (2011-02-14 10:31:49) (reply to #12)
If you have problems, please report concrete bugs.

#13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10)
Seems like this is done for 11.4

#14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25)
Nice

#16: Mindaugas Baranauskas (embar-) (2011-02-16 13:48:26) (reply to
#14)
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

+ #17: Roger Luedecke (shadowolf7) (2011-06-01 23:07:35)
+ Kpackagekit is not only problematic and inefficient, it is redundant.
+ Remove from 12.1.




--
openSUSE Feature:
https://features.opensuse.org/305394

< Previous Next >
This Thread