Feature changed by: Christoph Thiel (cthiel1)
Feature #303535, revision 32
Title: Use libnetapi to join Active Directory
openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov)
reject date: 2008-07-07 14:56:26
reject reason: Postponing.
openSUSE-11.2: Rejected by Christoph Thiel (cthiel1)
reject date: 2009-07-16 11:15:21
reject reason: no resoureces for 11.2
- openSUSE-11.3: Evaluation
+ openSUSE-11.3: Rejected by (cthiel1)
+ reject date: 2010-07-13 15:21:46
+ reject reason: not done.
Requested by: Ralf Haferkamp (rhafer)
Starting with 3.2.0 Samba will contain libnetapi, which is a C API
providing features required to join an Active Directory Domain. The
"Windows Domain Membership" YaST Module should switch to use this API
instead of calling the "net" command. This should make the Module much
easier to maintain
#9: Jiri Srain (jsrain) (2008-07-07 13:53:26)
Stano, please, postpone. Minimal gain, it would requre to write a new
C++ agent, and use code which has not been used before for this
Let's stay with proven method and experiment with a new one for 11.2.
#11: Matthias Eckermann (mge1512) (2008-07-14 20:37:06)
Ralf and Samba-Team: is this reject acceptable for you - or will this
have negative impact on AD integration?
#12: Ralf Haferkamp (rhafer) (2008-07-28 11:51:48) (reply to #11)
Jim, could you please answer Matthias' question I am not sure if
libnetapi does provide anything that we need in SLED10, which is not
provided by the "net" command.
#13: James McDonough (jmcdough) (2008-07-29 07:22:45) (reply to #12)
It is not advisable, but it is acceptable for now. Initially, it will
simply mean that we are more exposed to the net command format changes,
or any of the possible problems caused by running and interpreting
output from external commands.
Longer term, it should be done, as any new function will be implemented
first through libnetapi, and not necessarily exposed through the net
Feature added by: Vincent Petry (PVince81)
Feature #306766, revision 1
Title: Show new and updated package versions in zypper/yast
Requested by: Vincent Petry (pvince81)
After refreshing a repository, it would be nice to have a feature that allows to see which new packages have appeared and which package version has changed since the last refresh, like smart does.
This could be done by adding an extra information in the package list row, either as icon or color, or field.
Feature added by: Thiago Sayao (sayao)
Feature #310004, revision 1
Title: use network manager by default instead of traditional method
Requested by: Thiago Sayao (sayao)
Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN).
I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss.
Feature added by: Michal Marek (michal-m)
Feature #310110, revision 1
Title: LXR instance for openSUSE/SLE kernels
Hackweek V: Unconfirmed
Requested by: Michal Marek (michal-m)
Set up an LXR (http://lxr.linux.no/) for the openSUSE / SLE kernels. See also fate 309637.
Feature added by: Dirk Mueller (dirkmueller)
Feature #310102, revision 1
Title: Provide ability to search for rpm provides in End User Search
Requested by: Dirk Mueller (dirkmueller)
Currently the search at http://software.opensuse.org/search does not search for rpm provides, which could be used to enhance the search results (or rank newer/better versions of a package higher).
example: user searches for kde4-katomic, and there is a package in KDE:Distro:Factory that Provides/Obsoletes kde4-katomic. This package (named katomic) should be return as a fuzzy search result.
- end user search: can't search for rpm provides (novell/bugzilla/id: 0)
Feature changed by: Petar Petrov (Siminin)
Feature #305394, revision 40
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.
Requested by: Duncan Mac-Vicar (dmacvicar)
Partner organization: openSUSE.org
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
* 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
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.
- kpackagekit author interview (url:
- kpackagekit screenshot (url:
* 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
* 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
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.
#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
Bugs on the Gnome PK applet should be fixed -- lets make sure they are
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
#11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to
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
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
+ #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.