January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 120326] Resume download
by fate_noreply＠suse.de 24 Jan '09

24 Jan '09

Feature changed by: James Mason (bear454) Feature #120326, revision 45 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitri Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) Please stop this "I vote for this" or "+1" or "mee too" comments. There is no voting system in FATE yet, but following a discussion about "I want this too" makes hard to evaluate features. + #17: James Mason (bear454) (2009-01-24 06:05:01) + Could this be accomplished using a bittorrent backend instead of curl + ? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120326

1 0

[openFate 305715] Package event framework
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305715, revision 6 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affectiong it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) + Discussion: + #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) + This is desirable only as it happens within RPM's framework (or if the + additions are "candy" that does not affect the actual result). This + includes upstreaming. + I do not want to comment besides the RPM requirement until Engineering + determines how (and if) to proceed. There are too many factors + involved. + Stano, Needinfo me back when you guys have a settled position or decide + to postpone this one given the other priorities. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305715

1 0

[openFate 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305588, revision 5 Title: kdump support for autoyast installation - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305588

1 0

[openFate 301175] Update Messages Handling
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #301175, revision 28 Title: Update Messages Handling openSUSE-10.2: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2006-11-23 08:29:21 reject reason: not done in time... Priority Requester: Mandatory Projectmanager: Important openSUSE-10.3: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2007-08-07 11:17:55 reject reason: Solution needs to be integrated earlier in the release Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Requested by: Marcus Meissner (msmeissn) Partner organization: openSUSE.org Description: During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. In general, it is not possible to send emails from rpm install scripts. Most cases could be handled by the release notes but there are cases that cannot and we need a better solution to present this, especially since many people to not read the local emails. Relations: - update-messages functionality not implemented (novell/bugzilla/id: 4500930) https://bugzilla.novell.com/show_bug.cgi?id=4500930 Discussion: #2: Hendrik Vogelsang (hennevogel) (2006-09-05 14:52:12) Cleanup the messages and readd the features we lost with the removal of SUSEPlugger to zen-updater or whatever? #3: Duncan Mac-Vicar (dmacvicar) (2006-11-02 11:48:15) Current patches offer the message feature, so you could basically offer that package as a patch. If that is not sufficient, I propose something: We add a /var/spool/zypp-messages or something, and a binary which rpm spec call to inject messages. The zypp backend of the applet, check the spool in every check and use knotify to notifiy the user. I am only missing, where does the current rpm inject the messages to? #5: Edith Parzefall (emapedl) (2007-02-01 17:30:54) Andreas: any comments on the proposed solutions? #6: Duncan Mac-Vicar (dmacvicar) (2007-07-27 15:58:07) A proposal for normal packages: Create a dbus/dcop interface both applets implement. * create a /usr/sbin/update-messsage wrapper that allows rpms to send a message. * the wrapper sends a dcop/dbus message to the applets, which in turn show a passive popup? Other ideas? #7: Edith Parzefall (emapedl) (2007-08-06 13:50:22) Coolo, should we go ahead with the proposed solution and make a late feature admission request? #8: Stephan Kulow (coolo) (2007-08-06 19:18:17) (reply to #7) No, this requires documentation changes I'm not willing to accept. So I rather stay with the status quo ;( #9: Edith Parzefall (emapedl) (2007-08-07 11:05:55) Then please reject for 10.3. #10: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:19:05) Please reject for 11.0. All resources allocated with mandatory features already. #11: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:32:22) Please reject for SLE11/11.1. All resources allocated with mandatory features already. #12: Marcus Meissner (msmeissn) (2008-12-03 15:50:15) This was promised as "will be done" to the Maintenance Department. Mark it Mandatory for SP1. + #13: Federico Lucifredi (flucifredi) (2009-01-23 15:39:07) (reply to + #12) + please note, any solution must not break "RPM only" compatibility - meaning + these should be notification messages, not scripts used in any event to + finish configuration or to cause "side effects" of any kind. + #14: Federico Lucifredi (flucifredi) (2009-01-23 15:38:53) + I disagree with the rationale that users don't read local mail. An + admin should have that local mail forwarded, and I think we ought to + facilitate configuring the forwarding even to other machines. + I think that may have more success than popups... at least for + Enterprise customers. For community use, sure, popups are helpful (as + init 5 is more likely :-) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301175

1 0

[openFate 305491] package names should also be binary names
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305491, revision 30 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) After discussion with Michal, we'll add -p parameter to each module, which will indicate that package name is provided, not search_term. All modules will benefit from that change, not only "bin", so user could also list all java classes from java package and so on. I'm not quite sure about the command-not-found integration. There are some people who don't like the speed of handler and another extra search will add another fractions of seconds. If user wants that feature, he'll just types: $ scout bin -p MPlayer #20: Pavol Rusnak (prusnak) (2009-01-12 17:58:19) (reply to #19) I pushed change into scout git repo which adds -p option to all modules. Updated packages are also available from home:prusnak:scout repository. Feel free to test. $ scout bin mplayer repository | package | path | binary ----------------+---------+----------+--------- zypp (packman) | MPlayer | /usr/bin | mplayer $ scout bin -p MPlayer repository | package | path | binary ----------------+---------+----------+---------- zypp (packman) | MPlayer | /usr/bin | mplayer zypp (packman) | MPlayer | /usr/bin | gmplayer zypp (packman) | MPlayer | /usr/bin | mencvcd zypp (packman) | MPlayer | /usr/bin | mencoder #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. + #21: Federico Lucifredi (flucifredi) (2009-01-23 15:18:04) + Wow. What a discussion. + Stano, we spoke with Michal last year about adopting someone's Hack + Week work to provide hinting just the way Ubuntu does (when typing a + command name that is not in the system, suggest " zypper in + [packagename]" with the appropriate package. + This is a duplicate of another feature, and something already agreed + on. Package renaming seems unlikely, but hinting was in the list since + 11.0. + Stano, can you please give us the status on that, and close this + feature as duplicate if you can find the other ? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305394, revision 5 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305394

1 0

[openFate 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305317, revision 5 Title: Default to hidden bootloader menu - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) + Partner organization: openSUSE.org Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305317

1 0

[openFate 305324] Netcontrol does not set up WLAN when kill switch activated
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305324, revision 3 Title: Netcontrol does not set up WLAN when kill switch activated - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Marius Tomaschewski (mtomaschewski) + Partner organization: openSUSE.org Description: Provide udev rule to activate / deactivate WLAN interface based on killswitch event --- On my Lenovo ThinkPad T60p, the WLAN hardware kill switch doesn't work as expected. I am _NOT_ using NetworkManager, but the traditional ifup method. The problem seems to be, that the wlan interface is not properly brought up/down when I use the kill switch. --- This wont be fixed for 11.0, because there are different types of killswitch events for different drivers. And it works with NetworkManager. But for 11.1 we should be able to handle it more easily. There will be unified killswitch events. What we need is a additional udev rule that calls ifup for that event. Relations: - Netcontrol does not set up WLAN when kill switch activated (novell/bugzilla/id: 383309) https://bugzilla.novell.com/show_bug.cgi?id=383309 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305324

1 0

[openFate 305326] 5 Second Boot
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305326, revision 5 Title: 5 Second Boot - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Jared Allen (jpallen) + Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): - As we continue to get more involved in the Thin Client and UMPC - markets, boot time becomes increasingly important. Intel's Moblin - project is touting boot time as one of the significant + openSUSE.org: As we continue to get more involved in the Thin Client + and UMPC markets, boot time becomes increasingly important. Intel's + Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305326

1 0

[openFate 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305394, revision 4 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) + 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): - 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). + 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305394

1 0