November 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308339] Universal installer
by fate_noreply＠suse.de 30 Dec '09

30 Dec '09

Feature added by: Gerrit Mackor (itbgjm) Feature #308339, revision 1 Title: Universal installer Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Gerrit Mackor (itbgjm) Partner organization: openSUSE.org Description: Hello I would like to see a universal installer for Linux that works on all distros. Something that can do all the install work from a installer file and data files if necessary. They way I see it is that this will make developing applications for Linux more interesting as users will no longer need to use the MAKE utility or scripts pretty much meaning that the user is super user. This is on bit of software that will take Linux from the hobby environment to a more usable alternative. Using openSUSE I see that often I am asked for librarys. As an end user I do not really care what libraby is used, the application needs to work and all other apps need to work. Hope this will be possible. UPDATE: It seems that the installer part is being worked on. Se an extract on an interview below: -------------------------------------------------------------------------------- AJ: There are certain things that make a lot of sense, especially in RPM. When you release software as source code you want people to make binaries - it helps a lot if you make a .spec file. But if one .spec file only works on one distribution, and you have to write another .spec file for another distribution, it's not easy. That's what we're trying to solve - we're working on guidelines of how to write .spec files. We're working on RPMs having the same sets of patches, so that they get upstream as much as possible. TR: I'd like to see package names becoming uniform across distros... AJ: That will be the discussion as well, moving forward... a naming scheme, like Debian has with shared libraries. That's one aspect of distributions working together. -------------------------------------------------------------------------------- Taking the above a little further would be to remove the libraries from end users' view. As an end user I do not care what library I need. I would like to install an application and it must simply work. Business case (Partner benefit): openSUSE.org: Make Linux easier to use for an end user. -- openSUSE Feature: https://features.opensuse.org/308339

1 2

[New: openFATE 308398] Visual checkfs on boot
by fate_noreply＠suse.de 27 Dec '09

27 Dec '09

Feature added by: Alberto Garcia (trebol-a) Feature #308398, revision 1 Title: Visual checkfs on boot Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Alberto Garcia (trebol-a) Description: When the system (EXT3) is booting, launch a checking of filesystem every 65 days. A non-advanced user, one day, suddenly, that your computer take a long time and not show the Desktop... ...wait... and wait ...and press RESET button again. On several home computers that I maintain, the normal time of boot is ( about 1-2 minutes), one day, is multiplied by 10 or 20 WITHOUT visual indications. Is posible that openSuse show an visual alert over splashScreen in these situations? Some special loading icon of "extraordinary delay by checking FS, a moment please ...."? Regards -- openSUSE Feature: https://features.opensuse.org/308398

1 2

[New: openFATE 308305] Add dotted rectangle enclosing virtual partitions in partitioner's graph view
by fate_noreply＠suse.de 27 Dec '09

27 Dec '09

Feature added by: Marco Poletti (poletti_marco) Feature #308305, revision 1 Title: Add dotted rectangle enclosing virtual partitions in partitioner's graph view Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Marco Poletti (poletti_marco) Description: In the Graph view of the Partitioner, logical and primary partitions are displayed in the same way and the extended partition isn't shown. I would display a dotted rectangle around logical partitions. If there are no logical partitions I would still display an empty dotted rectangle if there is an extended partition. I reported this as a bug (540635), but it's not considered important enough to implement. I agree this is not high priority, but it would be nice to have IMHO. -- openSUSE Feature: https://features.opensuse.org/308305

1 2

[openFATE 307903] Support automatic-debuginfo installation.
by fate_noreply＠suse.de 16 Dec '09

16 Dec '09

Feature added by: Michael Andres (mlandres) Feature #307903, revision 1 Title: Support automatic-debuginfo installation. openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Michael Andres (mlandres) Partner organization: openSUSE.org Description: YaST currently does not support automatic-debuginfo installation. Business case (Partner benefit): openSUSE.org: See https://bugzilla.novell.com/show_bug.cgi?id=237741 -- openSUSE Feature: https://features.opensuse.org/307903

1 3

[openFATE 306007] Ship more vanilla
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature added by: Klaas Freitag (kfreitag) Feature #306007, revision 1, last change by Title: Ship more vanilla openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: Upstream projects such as KDE 4 often are developed with very high care for usability, design and eye candy, staffed with high skilled specialists and/or artists. openSUSE modifications against the vanilla versions sometimes do not really improve the upstream version. Moreover, these kind of modifications often kind of rebrand the projects, for example by replacing the KDE startmenu button by an openSUSE branded one. The openSUSE distribution as a community project should maintain the brand of the upstream projects and not hide them from the distributions users. Also patching vanilla behaviors where not technically needed or fixing problems should be handled very carefully and only happen in good dialog with upstream. -- openSUSE Feature: https://features.opensuse.org/306007

1 11

[openFATE 307496] return to having no default desktop environment
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307496, revision 1 Title: return to having no default desktop environment openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: The recent decision that openSUSE needs a default desktop environment must be reverted. * This decision has lead to frictions between the openSUSE sub-communities of GNOME and KDE users which might ultimately result in a drain of supporters of one of these sub-communities to a different distribution. * A default choice during installation gives the wrong impression that even now openSUSE chiefly supports the defaulted desktop environment while the other one is to be used 'at one's own risk' * This decision has acutely affected openSUSE's position as the only distribution which credibly supports both desktop environment * The gains to be had through a 'default desktop environment' are minor to zero, the potential loss and damage to community caused by it is catastrophic -- openSUSE Feature: https://features.opensuse.org/307496

1 10

[openFATE 307065] Terminate DVD image creation and only provide LiveCDs and Net Installs
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Stephen Kellat (skellat) Feature #307065, revision 1 Title: Terminate DVD image creation and only provide LiveCDs and Net Installs openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Stephen Kellat (skellat) Description: The discussion in openFATE #306967 relates to making KDE the default desktop environment for openSUSE. The question of choice arises there. A work-around to this would be to cease creating DVD images for installation and instead focus on LiveCDs and Net Install discs. Parity across desktop environments would be possible in having separate GNOME and KDE LiveCDs while also promoting Xfce into its own LiveCD instead of its obscurity on the DVD. As for Net Install discs, those are intended for experienced users so the rationale being exhibited in #306967 for catering to the needs of new users would not necessarily apply. Net Install discs could keep an expanded desktop environment choice list. Test Case: User desires GNOME experience in openSUSE and downloads the GNOME LiveCD. The kicker at http://software.opensuse.org would make the choice available to the user. Other users desire a KDE experience, an Xfce experience, or an LXDE experience would also be potentially directed by the kicker. ISO naming conventions would have to be adjusted to take into account the variety of LiveCDs possible. Use Case: Building LiveCDs decreases the amount of bandwidth to be consumed by potential users who would otherwise secure the DVD ISO. SUSEStudio could be tied in so that project leaders who were so minded could offer refreshed respins on their own outside the normal distribution cycle. -- openSUSE Feature: https://features.opensuse.org/307065

1 8

[openFATE 307495] GNOME default
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307495, revision 1 Title: GNOME default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: I propose to make GNOME the default desktop in openSUSE. It has been decided that users are overly challenged by having to decide between the GNOME and KDE desktop environments during the installation procedure. If this is true, such users will be overly challenged by the KDE desktop environment which is now planned to be the default choice. This proposal is meant to solve this problem by changing the default desktop environment for openSUSE to GNOME. These are the reasons why GNOME should be defaulted in openSUSE, not KDE: 1) By default an easy-to-use desktop environment should be installed: The way it is planned now, users who are uncertain about what desktop-environment they want because they are not tech-savvy or who don't know either KDE nor GNOME will end up with KDE because it will be defaulted. This basically means that those users who are most in need of a newbie-friendly desktop will get KDE. This clearly is wrong. KDE is an expert-desktop; it's strength is that its highly configurable. This is not what new and/or non-tech-savvy users want, nor is it what they need. KDE users are usually technically advanced and will know how to click the 'KDE' tickbox, while newbies should get GNOME. 2) Consistency with the NOVELL SUSE LinuxEnterprise Linux releases: Users who have heard about SLED/SLES will expect openSUSE to resemble those enterprise-level distributions. They will feel short-changed if they are presented with the unfamiliar KDE-desktop after an openSUSE install 3) GNOME is the world's standard Linux desktop environment: In order to compete on a global level, we should adopt the world's favored Linux desktop environment. The mainly regionally (Germany/Europe) successful KDE is not the solution for international success but a niche product. All globally successful distributions use GNOME; such as Red Hat Enterprise Linux, Fedora, Debian and most prominently Ubuntu. 4) Ubuntu: We must present a strong alternative to Ubuntu. This can NOT be a KDE desktop as we can see by the relatively low popularity of Kubuntu. KDE can never attract more than a minority of expert users. We must build on the innovations that won SLED awards and popularity. 5) Innovation: To say it outright, KDE had its chance to innovate and failed. KDE 4 was a massive disappointment even to hard-core KDE users in that it produced no enhancement to user-experience nor stability. With the upcoming GNOME 3 release openSUSE has the chance to present revolutionary user experience by the introduction of Gnome-shell as an alternative UI, while still providing more users with the option to continue using the traditional GNOME UI. 6) Attracting developers: What openSUSE already has is an abundance of contributors to KDE. We now urgently need to attract more GNOME developers by focusing on GNOME development and showing commitment to success in our competition with Ubuntu. openSUSE should, of course, also ship and support KDE. So experienced users can choose it. But new users should have GNOME as a default. Please note that I would have preferred if openSUSE had remained with its policy of treating both desktop-environments as equals, but unfortunately, following a request by some KDE-proponents, that policy has been changed to a popularity contest between both DEs by statistics and voting-contests in openFATE. This feature request is nothing but a neccessary reaction to proposal #306967, so that users have a choice to vote for either KDE or GNOME to be defaulted. -- openSUSE Feature: https://features.opensuse.org/307495

1 15

[openFATE 308183] Hdd Label
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: andrea martin (Il_Cjargnel) Feature #308183, revision 1 Title: Hdd Label openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: andrea martin (il_cjargnel) Description: Is posible in yast2-->partitioner make a boxtest for canghe a label of hard disk / partition? Thank's by Andrea -- openSUSE Feature: https://features.opensuse.org/308183

1 1

[New: openFATE 308249] ability of disable IPv6 auto-configuration
by fate_noreply＠suse.de 05 Dec '09

05 Dec '09

Feature added by: Per Jessen (pjessen) Feature #308249, revision 1 Title: ability of disable IPv6 auto-configuration openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: Add a setting in /etc/sysconfig/network/ifcfg-XXXX to specify "Do not auto-configthis interface for IPv6". Business case (Partner benefit): openSUSE.org: It would appear that other distros, e.g. CentOS, have the ability to specify that a network interface should not be auto-configured for IPv6. This is useful when the interface will not be used for IPv6, e.g. for PPPOE. -- openSUSE Feature: https://features.opensuse.org/308249

1 1

[openFATE 306976] Incluir Firefox en qt4 en forma predeterminada
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Luis Bodino (luigi_bodino) Feature #306976, revision 1 Title: Incluir Firefox en qt4 en forma predeterminada openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Luis Bodino (luigi_bodino) Description: Propongo que se use la versión qt de firefox para una mejor integración con kde -- openSUSE Feature: https://features.opensuse.org/306976

1 9

[openFATE 307381] Include PDF Mod
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Gabriel Burt (gabrielburt) Feature #307381, revision 1 Title: Include PDF Mod openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Gabriel Burt (gabrielburt) Description: PDF Mod is a new tool for doing simple manipulations to PDF documents, including removing, rotating, and extracting pages. -- openSUSE Feature: https://features.opensuse.org/307381

1 10

[New: openFATE 308402] Add init script for timidity
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Michal Seben (mseben) Feature #308402, revision 1 Title: Add init script for timidity openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Seben (mseben) Description: Add init script to timidity daemon (Ubuntu already do this) -- openSUSE Feature: https://features.opensuse.org/308402

1 8

[New: openFATE 308420] define and use repo index service for opensuse
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Josef Reidinger (jreidinger) Feature #308420, revision 1 Title: define and use repo index service for opensuse openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Josef Reidinger (jreidinger) Description: Hi, we should define Repo index service for opensuse ( http://en.opensuse.org/Standards/Repository_Index_Service ). advantage: - easy upgrade via zypper and other services - easy to testing latest snapshot - very easy to do it disadvantage: - I don't see anything There should be 2 services. 1) default one is opensuse_release...it defined repository for latest stable repository, so now 11.2 oss, non-oss, debug and update and after we release 11.3 then it switch to 11.3 repositories and user just need to refresh service and run zypper dup 2) testing for opensuse snapshot. It points to snapshot of development version of opensuse, so user could easy switch between alpha2 and alpha3 just updating repository and run zypper dup. Use Case: User A want update from 11.1 to 11.2. Now he must update manually all repositories and run zypper dup. Afterwards, it is enough to refresh service and run zypper dup, which is more easy. -- openSUSE Feature: https://features.opensuse.org/308420

1 4

[openFATE 306028] A log structured filesystem like nilfs as root file-system for SSD based devices
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Robert Davies (robopensuse) Feature #306028, revision 13 Title: A log structured filesystem like nilfs as root file-system for SSD based devices openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-06-24 12:31:45 reject reason: Out of scope for 11.2 Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Nikanth K (nikanth) Description: A log structured file-system like nilfs as root file-system to use on SSDs. Currently GRUB does not have support for those file-systems. So may be an option to have LILO for those configurations or add support for those in GRUB. Relations: - feature/duplicate: 306585 Discussion: #4: Nikanth K (nikanth) (2009-05-07 14:36:45) Another option would be to have a /boot partition(or disk) and allow the root partition(or disk) as nilfs(or btrfs). I guess this should require only YaST changes. No LILO support required. + #6: Robert Davies (robopensuse) (2009-11-30 20:19:17) (reply to #4) + No changes needed to YaST, I do the small (ext2 with 4k blocks & few + inodes) via Custom Paritioning and then copy files to a "shared" /boot + partition after an install. + lilo(8) is indeed not required. So all this needs is support of nilfs + in the kernel, expert partitioner and a nilfs-tools package analagous + to reiserfs(8) (would have mentioned btrfs or ext4 but they seem to + have funked the man pages). -- openSUSE Feature: https://features.opensuse.org/306028

1 0

[New: openFATE 308430] Package Rapid Photo Downloader
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature added by: Damon Lynch (damonlynch) Feature #308430, revision 1 Title: Package Rapid Photo Downloader Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Damon Lynch (damonlynch) Description: Rapid Photo Downloader for Linux is written by a photographer for professional and amateur photographers. Its goal is to be the best photo downloader for the Linux Desktop. Main features: 1) Generates meaningful, user configurable file and folder names 2) Downloads images from multiple devices simultaneously 3) Backs up images as they are downloaded 4) Easy to configure and use 5) Runs under Gnome, KDE and other Linux desktop environments 6) Available in twelve languages 7) Program configuration and use is fully documented License: GPL. Website: http://damonlynch.net/rapid/ (http://damonlynch.net/rapid/) -- openSUSE Feature: https://features.opensuse.org/308430

1 0

[openFATE 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Robert Davies (robopensuse) Feature #304911, revision 29 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. Priority Requester: Desirable openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 10:55:19 reject reason: 21 votes, but noone volunteering Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:41:45) (reply to #1) cute. It is a nice idea indeed. #3: Dmitry Mittov (michael_knight) (2009-02-23 11:03:50) It is not a good idea to add gpg keys for all repos all over the world. What do you want to do with new repos on BuildService? They can be created after release of new Suse version. All repos signed with SuSE Package Signing Key are guaranteed. When you add other repos you should confirm you trust them. But special option for 'zypper ar'. Something like '--trust-key' will solve you problem. #4: Stephan Kulow (coolo) (2009-04-16 14:41:15) (reply to #3) you haven't see the community repos list yet? #5: Stephan Kulow (coolo) (2009-04-16 14:41:42) looking for community volunteers #6: Stanley Miller (stan_qaz) (2009-04-30 04:10:50) Would it be possible to do a quick check to see which repositories do not have the keys already downloaded and do the dialog box for all of them before starting the metadata download? That avoids the issue of just accepting the keys blindly and the issue of having the download process stop and wait for user input when a missing key is found. #7: T. J. Brumfield (enderandrew) (2009-06-13 02:14:59) You have to go out of your way to add the repo in the first place. Can someone please explain a scenario where you would go out of your way to add the repo, and then reject the GPG key? #8: Stephan Kulow (coolo) (2009-08-12 10:55:57) (reply to #7) community repositories lets you add several repos at once #9: Todd R (theblackcat) (2009-09-22 18:28:10) (reply to #8) But isn't that a list of repositories trusted by openSUSE? #10: Marcus Meissner (msmeissn) (2009-09-23 00:27:38) (reply to #9) Not by the distribution itself, no. Some of the repositories are built with less security and less quality than the distribution itself. There shouyld perhaps be a two step process in the end .. seperate "known keys" ... "unknown keys" and "trusted keys" :/ + #11: Robert Davies (robopensuse) (2009-11-30 18:59:58) (reply to #10) + Can't the Distro include keys for repo's like Packman & libdvdcss + which high proportion of user will add. It's certifying the identity + of the repo for better security not installing (or inducing install of) + any potentially illegal software. + The highish quality repos ought to be recognised, as training user to + blindly accept certificates is counter-productive from security pov. -- openSUSE Feature: https://features.opensuse.org/304911

1 0

[openFATE 305158] Make summary of partitioning changes more readable
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Robert Davies (robopensuse) Feature #305158, revision 10 Title: Make summary of partitioning changes more readable openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 16:23:32 reject reason: no resources for 11.2 Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Before applying the changes made by the partitioner the user is presented by a colorful pop up (http://en.opensuse.org/Image:Part_current_popup.png) The idea is to replace this pop up by a nice, clearly structured full screen summary (http://en.opensuse.org/Image:Summary_partitioner.png) The summary lines ("partition X will be formatted", "fstab options changed for partition Y") come from libstorage and the interface is pretty generic so far. In other words, it has no support for grouping the lines (putting hard disk related msgs together, similarly with LVMs, RAIDs etc.) According to developers it would require significant changes to libstorage. + Discussion: + #1: Robert Davies (robopensuse) (2009-11-30 18:45:35) + Odd this is down as 'rejected' because there's no pop up in 11.2, and + AFAIR the info is well presented and pretty readable. -- openSUSE Feature: https://features.opensuse.org/305158

1 0

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Robert Davies (robopensuse) Feature #303873, revision 17 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 17:47:05 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) + #5: Robert Davies (robopensuse) (2009-11-30 17:48:32) + Recent installs of oS (11.[12] feature few license agreements, surely + user pays price for an addiction to proprietary software if they get + very many. There would seem to be other areas in YaST UI which would + give majority more benefit than a rarely used license overview of type + shown (though it looks nice). A way package installation history + springs to mind. -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Roberto Mannai (robermann79) Feature #300758, revision 101 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). + #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) + The user could have a graphical list of "undependent packages", which + then he could mark each of them as "used/not used". The GUI then could + suggest the "unused packages" for removal (this being a temporary but + useful use case). -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 302446] Power consumption gauge
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Robert Davies (robopensuse) Feature #302446, revision 40 Title: Power consumption gauge openSUSE-11.0: Rejected by Gary Ekker (gekker) reject date: 2008-05-09 10:28:15 reject reason: Nothing done for 11.0. Priority Requester: Desirable openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-09-10 16:50:33 reject reason: Dependent feature not complete. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 12:06:48 reject reason: too late for 11.2 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Frank Seidel (fseidel) Description: Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power- manager (to be discussed). Its intent is to make the user aware when the system starts to hog power (e.g. after starting some bad behaving application that polls "expensive" hardware all the time). Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power-manager (to be discussed). Relations: - provide common source for a overall battery time information (feature/id: 303749) Documentation Impact: Needs to be documented Discussion: #1: Michael Löffler (michl19) (2008-02-01 11:56:22) In regards of Green IT theme for SLE 11 this sounds like useful thing. #2: Stefan Behlert (sbehlert) (2008-05-29 23:23:48) (reply to #1) Right.. #4: JP Rosevear (jproseve) (2008-06-02 13:52:01) Christian, can we actually aggregate power consumption information from somewhere? If so, getting a gui on top of it should be straight forward. #5: Christian Zoz (zoz) (2008-06-19 15:03:57) Power consumption information is only available when the system runs on battery. But i guess on ac-power this info is less interesting anyway. We can get this information via ACPI. Not really power consumption, but power drain of each battery. I suggest that hal can provide individual drain and aggregate overall power consumption. For that have a look at feature: #303749: provide common source for a overall battery time information #6: Rodrigo Moya (rodrigomoya) (2008-09-08 14:43:35) For gnome-power-manager, we already have something like this (right- click -> power history), it shows lots of information about powe consumption. Isn't this enough? #7: JP Rosevear (jproseve) (2008-09-10 16:49:55) Fate 303749 is not complete, so I think I have to reject this. #9: ali ershad-manesh (gorbehnare) (2009-04-30 07:09:01) I'm not a developer, and I just know a little about computers, however I don't think the computer can measure power consumption in the first place. I don't think the Power Supplies are smart enough or connected enough yet to give that information. At least to the best of my knowledge. On a laptop running on battery some power drain can be calculated to estimate the battery life. On a desktop... I don't think it's going to work. I have a UPS that comes with a monitoring software that shows the power consumption . It runs a little Java based GUI that shows power status. Unfortunately the UPS software only works in Windows and is very hardware specific to this particular UPS. If someone needs these kind of information a UPS with Linux compatible software might just do the trick! #11: Matthias Nagorni (mnagorni) (2009-08-24 12:36:25) It really depends on the user scenario: For a Thin Client type of installation you would probably want to hide this level of system detail, however for notebook usage it appears to be very useful. Therefore "Important" but should be configurable. #13: Klaas Freitag (kfreitag) (2009-08-25 11:58:09) Sorry, we're not working for SLE SPs. + #16: Robert Davies (robopensuse) (2009-11-30 17:35:07) + Could something using wake ups & idle time reporting do most of the + job, and be more generally useful like powertop? Then actually this is + interesting on some mains systems to, things like virtualised servers, + or with high machine density in data-centre. Also perhaps on desktop + where poor applications cause noise from cooling fans. -- openSUSE Feature: https://features.opensuse.org/302446

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Roberto Mannai (robermann79) Feature #300758, revision 100 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. + #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) + +1 Kornél + Regarding Case A: of course "not needed package" is a subset + "undependent package" - "not needed" catches the user's point of view + and it is more precise. Nevertheless, determining that "not needed" + packages is a hard job, so it could be a good starting point just + knowing which are the "undependent" ones (at least as a first step). -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Kornél Jahn (cornail) Feature #300758, revision 99 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. + #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) + I also support the not needed / no longer needed version. Orphaned is + bad since it can be misunderstood, just like "undependent package", if + Roberto meant to suggest it as a description for this phenomenon. + Case A: If I install manually package X, which doesn't have any + dependencies nor is it referred to by any other package, it is not a + "not needed" one. 'Cause it was manually installed by the user. + Case B: Package X is installed automatically as a dependency while + installing package Y. Package Y is then removed, but X stays, with no + other package referring to it as a dependency. X is then a "not needed" + package. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Roberto Mannai (robermann79) Feature #300758, revision 98 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. + #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) + Undependent packages : packages which don't have any(more) + dependency. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #300758, revision 97 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important - openSUSE-11.2: Rejected by (jkupec) + openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. + #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) + Thomas suggests that perhaps not needed (or no longer needed ) would be + better than unused since 'unused' can be confused with 'not used by + user' rather than 'not used by other packages'. -- openSUSE Feature: https://features.opensuse.org/300758

1 0