September 2014 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 314662] Use a "green Adwaita" GTK theme
by fate_noreply＠suse.de 11 Nov '14

11 Nov '14

Feature added by: Michael Catanzaro (Golbats_Everywhere) Feature #314662, revision 1 Title: Use a "green Adwaita" GTK theme openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Michael Catanzaro (golbats_everywhere) Partner organization: openSUSE.org Description: openSUSE 12.1/12.2 uses the upstream Adwaita GTK theme. This is mostly good, since it's a very high-quality theme, and I believe one of our goals is to not diverge much from the upstream GNOME experience. However, GNOME's main color is blue, whereas ours is green. When highlighting text, the highlight is blue. When selecting an item in a list, the background turns blue. When selecting the scrollbar, the scrollbar turns blue. When typing into a text form, the form is outlined in blue. I propose we change the blue elements of Adwaita to green elements (by default). This should be all that is changed, so that the theme remains simple to maintain and retains the GNOME feel. I separately propose using the Sonar icon set by default in GNOME, which still works great in 12.2 and is very very close to upstream GNOME. This is not essential to the overall proposal. Screenshots of a mockup: Current: http://paste.opensuse.org/92804741 Proposed: http://paste.opensuse.org/31898989 Current: http://paste.opensuse.org/33805016 Proposed: http://paste.opensuse.org/27086964 Current: http://paste.opensuse.org/13532791 Proposed: http://paste.opensuse.org/57771364 Business case (Partner benefit): openSUSE.org: A green Adwaita theme would fit both upstream GNOME and also openSUSE, and would add a level of polish and integration to the distro. The current "blue Adwaita" theme feels out of place in openSUSE, particularly considering the attention to artistic detail in other parts of the distribution. -- openSUSE Feature: https://features.opensuse.org/314662

1 8

[New: openFATE 311336] zypper lr --active - list only active repos
by fate_noreply＠suse.de 06 Nov '14

06 Nov '14

Feature added by: Christian Boltz (cboltz) Feature #311336, revision 1 Title: zypper lr --active - list only active repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: I often find myself to run zypper lr | grep 'Yes *|' to get a list of all active repos on my system. A zypper option would be useful for this - something like zypper lr --active (not sure about the short version of this option, because the obvious ones (-a, -A) are already taken.) -- openSUSE Feature: https://features.opensuse.org/311336

1 1

[New: openFATE 314473] Replace pwdutils with shadow utilities
by fate_noreply＠suse.de 23 Oct '14

23 Oct '14

Feature added by: Thorsten Kukuk (kukuk) Feature #314473, revision 1 Title: Replace pwdutils with shadow utilities Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: The pwdutils are from a time where the shadow utilities did not had a maintainer and the patches every Linux distribution had were longer then the whole source code. Meanwhile the upstream project is active again and most patches where accepted. Thus we should switch to the shadow project to get all the advantages (for example acl,extended attributes,selinux support). Relations: - README.changes-pwdutils (url: https://build.opensuse.org/package/view_file?file=README.changes-pwdutils&p…) -- openSUSE Feature: https://features.opensuse.org/314473

1 7

[New: openFATE 308967] Allow Oracle Instant Packages
by fate_noreply＠suse.de 18 Oct '14

18 Oct '14

Feature added by: Ciro Iriarte (ciriarte) Feature #308967, revision 1 Title: Allow Oracle Instant Packages Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Ciro Iriarte (ciriarte) Partner organization: openSUSE.org Description: Include Oracle Instant Client in openSUSE or at least, allow for creation and store in Build Service. This was attempted before but all the work was lost because the files were deleted from OBS. The InstantClient can be redistributed and it doesn't require any license to be used, the only issue is that it doesn't include source code. This can be handled like Sun's Java or Adobe Acrobat. Ref: http://lists.opensuse.org/opensuse-buildservice/2007-08/msg00311.html (http://lists.opensuse.org/opensuse-buildservice/2007-08/msg00311.html) http://lists.suse.com/archive/suse-oracle/2007-Aug/0055.html (http://lists.suse.com/archive/suse-oracle/2007-Aug/0055.html) Use Case: Creation of dependent packages like php-oci, Perl DBD::Oracle or TOra Business case (Partner benefit): openSUSE.org: To make easier the user's life, also this feature would be very attractive, providing Oracle connectivity from CLI, GUI, PHP and Perl out of the box, or at least really fast after adding the needed repository. -- openSUSE Feature: https://features.opensuse.org/308967

1 5

[New: openFATE 317247] detect more filesystems in YaST partitioner
by fate_noreply＠suse.de 06 Oct '14

06 Oct '14

Feature added by: Arvin Schnell (aschnell) Feature #317247, revision 1 Title: detect more filesystems in YaST partitioner Requested by: Arvin Schnell (aschnell) Partner organization: openSUSE.org Description: The YaST partitioner should detect more filesystems, e.g. UDF which is used on the Live USB sticks distributed at the openSUSE Conference 2014. This will give the user a better view of the system. -- openSUSE Feature: https://features.opensuse.org/317247

1 1

[New: openFATE 310516] YaST2 DNSSEC
by fate_noreply＠suse.de 02 Oct '14

02 Oct '14

Feature added by: Peter Bowen (pzb) Feature #310516, revision 1 Title: YaST2 DNSSEC openSUSE-11.4: New Priority Requester: Important Requested by: Peter Bowen (pzb) Description: With the root zone now being signed, DNSSEC is finally seeing adoption. It would be really nice for YaST to be able to generate a signed zone. -- openSUSE Feature: https://features.opensuse.org/310516

1 8

[New: openFATE 317942] Modern Pager for kde plasma
by fate_noreply＠suse.de 30 Sep '14

30 Sep '14

Feature added by: Belleux Olivier (Lord-Master) Feature #317942, revision 1 Title: Modern Pager for kde plasma openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Belleux Olivier (lord-master) Partner organization: openSUSE.org Description: The plasmoid "pager" is not suitable for managing a variable number of workspaces under kde 4 ; I suggest, for kde 4/5 a new plasmoid that displays the number of the current desktop id/total number of desktop like gnome-shell do;for changing of desktop it will be possible to use the mouse wheel or to shown a panel on left click. Maybe a "green plus" in the plasmoÃ¯d could help adding a new destop -- openSUSE Feature: https://features.opensuse.org/317942

1 0

[New: openFATE 315590] Support non-numeric names for md/raid devices.
by fate_noreply＠suse.de 30 Sep '14

30 Sep '14

Feature added by: Neil Brown (neilbrown) Feature #315590, revision 1 Title: Support non-numeric names for md/raid devices. Requested by: Neil Brown (neilbrown) Partner organization: openSUSE.org Description: mdadm-3.3 (due to be released July 2013) will support md device named like "md_home" as well as the traditional "md4". However these names are likely to confuses installers and other system managers so they are disabled by default. To get full benefit from these we need to: 1) Make sure initrd scripts in mdadm package handle these names. 2) teach yast-storage to be able to use non-numeric names and not to be confused by them 3) update any system administration documentation 4) check any system monitoring tools to ensure they won't get confused. Business case (Partner benefit): openSUSE.org: More friendly device names make for an improved user experience. -- openSUSE Feature: https://features.opensuse.org/315590

1 13

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 21 Sep '14

21 Sep '14

Feature changed by: Matthias Eckermann (mge1512) Feature #300758, revision 153 Title: Show unneeded 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-11.3: Done Priority Requester: Desirable Projectmanager: Important Requested by: JP Rosevear (jproseve) Product Manager: Vladimir Botka (vbotka) Partner organization: openSUSE.org Description: The package manager should learn to show unneeded 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). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) Such procedure would also wipe out packages that you still want to use. E.g. you have nagios-plugins-zypper, which requires zypper. Now, 'zypper remove nagios-plugins-zypper' would realize that after removing nagios-plugins-zypper nothing requires zypper, and would want to remove zypper as well. So what your idea lacks is a list of packages that were installed in the past based on explicit request by user. The procedure must avoid removing these. See also c#12 #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) So i'm renaming this fate request to 'Show unneeded packages' (to make it shorter) to avoid further confustion. #37: Don Hughes (dehughes) (2009-12-15 19:10:53) I also would like to see this feature. I currently use rpmorphan with a list of things that it will mark that I know that I need. I also occationally go through yast2 and try to uninstall things that I do not recognize and see if they are flagged as being needed by something else. Both time consuming and error prone. And, a lot of packages seem to be some what careless in what the require for prereqs - pulling in KDE,gnome, and X11 packages on text- only machines for example; which then triggers a flood of KDE, gnome, and X11 library installations which I then have to mannually uninstall and mark as taboo. On my external facing servers I do not like to have any extra/unneeded/unwanted packages to provide possible attack vectors. #39: Rafael Belmonte (eaglescreen) (2010-01-10 22:43:40) Hello, this is one of the main causes of I use more Debian/Ubuntu than OpenSuse. Debian & Ubuntu already have this implemented. I think this is a fundamental aspect to work in OpenSuse. Debian & Ubuntu can distinguish packages that were manually installed and packages that were installed just to satisfy dependencies. OpenSuse needs to do this too. #40: Tim Edwards (tk83) (2010-01-27 15:46:00) I'd also like to see this, Mandriva added it in a couple of releases ago and it's great. It's really missing in Opensuse #41: Eduard Huguet (eduardhc) (2010-03-02 15:55:43) (reply to #40) Agreed. Being a long time user of both Gentoo and Ubuntu, I was really shocked to discover that zypper was lacking this feature. Even more: when talking about Linux with friends I always make mention of this kind of "autoremove unneeded" option as one of the strong points of Linux package managing systems, as I was really taking for granted that any package manager out there had this feature included... Regards. #42: Rémy Marquis (spyhawk) (2010-05-02 17:13:32) Michael Andres started to implement this feature in Libzypp 7.4, see http://lists.opensuse.org/zypp-devel/2010-04/msg00033.html #45: Robin Knapp (rknapp) (2010-07-14 13:00:55) (reply to #42) --clean-deps works indeed, but what about just showing unneeded packages? It's mentioned in http://en.opensuse.org/Product_highlights#Package_management_with_zypper but I haven't found any information about this feature. #46: Moqi Ba (bamoqi) (2011-07-24 01:37:08) This FATE is marked as done but as of 11.4 "zypper rm -u" doesn't work without a package name. It cannot actively find and remove orphaned package which are auto-installed, like "apt-get autoremove" does. #47: Michael Schröder (mlschroe) (2012-02-13 12:34:53) (reply to #46) True. We can add that for 12.2, but the quality of the result really depends on knowing which packages were selected by the user and which packages were dragged in via dependencies. #49: Cristian Morales Vega (reddwarf) (2012-04-11 16:06:31) (reply to #47) That info is available already through the history, isn't? The only problem I know of is bnc#679213... that I have no idea if was fixed since the info is not public :-( #50: Jiri Srain (jsrain) (2012-08-21 11:52:03) (reply to #49) I have this information in the log of my 12.1. #54: Michael Schröder (mlschroe) (2012-12-20 16:29:00) (reply to #47) Just for completeness: 12.2 has an "unneded packages" package group. #48: Joachim Plack (jplack) (2012-02-13 13:58:53) For images generated in a SLEPOS environment, we would like the to reduce the footprint. So we'd like to find out all packages where last use (per read access time stamp) <= install time. This list we would the transfer back to the image creation server so that the next image gets reduce to what we really need. Btw. removedthe big list of rejected openSUSEs besides the first and last to get a better overview again while keeping the history #51: Jiri Srain (jsrain) (2012-08-21 11:54:04) (reply to #48) Jack, does this necessarily involve libzypp/zypper? I think that this is a rather specific use-case, which can be scripted easily. Besides, I suggest to handle this as a separate request - this one is about unneeded, not about unused. #55: Christian Kujau (ckujau) (2013-03-11 10:05:50) Why is this ticket set to "Done" (for openSUSE-11.3) - has this feature been implemented. I could not find anything related in zypper(8) in 12.3 - is a new ticket required to have this resolved? A possible (but possibly dangerous) workaround would be to use YUM: $ zypper install yum-utils $ zypper remove --dry-run `package-cleanup --quiet --leaves` The "--oldkernels" isn't working here though: package-cleanup --oldkernels Setting up yum Traceback (most recent call last): File "/usr/bin/package-cleanup", line 419, in <module> main() File "/usr/bin/package-cleanup", line 388, in main removeKernels(my, opts.kernelcount, opts.confirmed, opts.keepdevel) File "/usr/bin/package-cleanup", line 293, in removeKernels (kver,krel) = runningkernel.split('-') ValueError: too many values to unpack #56: Michael Schröder (mlschroe) (2013-03-11 10:58:37) (reply to #55) There's both "zypper remove --clean deps" and a "unneeded packages" group in YaST. #57: Christian Kujau (ckujau) (2014-09-21 06:24:30) (reply to #56) Sorry for the late reply, I haven't used openSUSE in a long time. "zypper remove --clean deps" is not working in 13.1, as "deps' is not a package. But "unneeded packages" in YaST works - thanks! # zypper remove --clean deps Loading repository data... Reading installed packages... 'deps' not found in package names. Trying capabilities. No provider of 'deps' found. Resolving package dependencies... Nothing to do. + #58: Matthias Eckermann (mge1512) (2014-09-21 12:11:17) (reply to #57) + The syntax is + zypper remove --clean-deps [packagename] -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 21 Sep '14

21 Sep '14

Feature changed by: Christian Kujau (ckujau) Feature #300758, revision 152 Title: Show unneeded 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-11.3: Done Priority Requester: Desirable Projectmanager: Important Requested by: JP Rosevear (jproseve) Product Manager: Vladimir Botka (vbotka) Partner organization: openSUSE.org Description: The package manager should learn to show unneeded 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). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) Such procedure would also wipe out packages that you still want to use. E.g. you have nagios-plugins-zypper, which requires zypper. Now, 'zypper remove nagios-plugins-zypper' would realize that after removing nagios-plugins-zypper nothing requires zypper, and would want to remove zypper as well. So what your idea lacks is a list of packages that were installed in the past based on explicit request by user. The procedure must avoid removing these. See also c#12 #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) So i'm renaming this fate request to 'Show unneeded packages' (to make it shorter) to avoid further confustion. #37: Don Hughes (dehughes) (2009-12-15 19:10:53) I also would like to see this feature. I currently use rpmorphan with a list of things that it will mark that I know that I need. I also occationally go through yast2 and try to uninstall things that I do not recognize and see if they are flagged as being needed by something else. Both time consuming and error prone. And, a lot of packages seem to be some what careless in what the require for prereqs - pulling in KDE,gnome, and X11 packages on text- only machines for example; which then triggers a flood of KDE, gnome, and X11 library installations which I then have to mannually uninstall and mark as taboo. On my external facing servers I do not like to have any extra/unneeded/unwanted packages to provide possible attack vectors. #39: Rafael Belmonte (eaglescreen) (2010-01-10 22:43:40) Hello, this is one of the main causes of I use more Debian/Ubuntu than OpenSuse. Debian & Ubuntu already have this implemented. I think this is a fundamental aspect to work in OpenSuse. Debian & Ubuntu can distinguish packages that were manually installed and packages that were installed just to satisfy dependencies. OpenSuse needs to do this too. #40: Tim Edwards (tk83) (2010-01-27 15:46:00) I'd also like to see this, Mandriva added it in a couple of releases ago and it's great. It's really missing in Opensuse #41: Eduard Huguet (eduardhc) (2010-03-02 15:55:43) (reply to #40) Agreed. Being a long time user of both Gentoo and Ubuntu, I was really shocked to discover that zypper was lacking this feature. Even more: when talking about Linux with friends I always make mention of this kind of "autoremove unneeded" option as one of the strong points of Linux package managing systems, as I was really taking for granted that any package manager out there had this feature included... Regards. #42: Rémy Marquis (spyhawk) (2010-05-02 17:13:32) Michael Andres started to implement this feature in Libzypp 7.4, see http://lists.opensuse.org/zypp-devel/2010-04/msg00033.html #45: Robin Knapp (rknapp) (2010-07-14 13:00:55) (reply to #42) --clean-deps works indeed, but what about just showing unneeded packages? It's mentioned in http://en.opensuse.org/Product_highlights#Package_management_with_zypper but I haven't found any information about this feature. #46: Moqi Ba (bamoqi) (2011-07-24 01:37:08) This FATE is marked as done but as of 11.4 "zypper rm -u" doesn't work without a package name. It cannot actively find and remove orphaned package which are auto-installed, like "apt-get autoremove" does. #47: Michael Schröder (mlschroe) (2012-02-13 12:34:53) (reply to #46) True. We can add that for 12.2, but the quality of the result really depends on knowing which packages were selected by the user and which packages were dragged in via dependencies. #49: Cristian Morales Vega (reddwarf) (2012-04-11 16:06:31) (reply to #47) That info is available already through the history, isn't? The only problem I know of is bnc#679213... that I have no idea if was fixed since the info is not public :-( #50: Jiri Srain (jsrain) (2012-08-21 11:52:03) (reply to #49) I have this information in the log of my 12.1. #54: Michael Schröder (mlschroe) (2012-12-20 16:29:00) (reply to #47) Just for completeness: 12.2 has an "unneded packages" package group. #48: Joachim Plack (jplack) (2012-02-13 13:58:53) For images generated in a SLEPOS environment, we would like the to reduce the footprint. So we'd like to find out all packages where last use (per read access time stamp) <= install time. This list we would the transfer back to the image creation server so that the next image gets reduce to what we really need. Btw. removedthe big list of rejected openSUSEs besides the first and last to get a better overview again while keeping the history #51: Jiri Srain (jsrain) (2012-08-21 11:54:04) (reply to #48) Jack, does this necessarily involve libzypp/zypper? I think that this is a rather specific use-case, which can be scripted easily. Besides, I suggest to handle this as a separate request - this one is about unneeded, not about unused. #55: Christian Kujau (ckujau) (2013-03-11 10:05:50) Why is this ticket set to "Done" (for openSUSE-11.3) - has this feature been implemented. I could not find anything related in zypper(8) in 12.3 - is a new ticket required to have this resolved? A possible (but possibly dangerous) workaround would be to use YUM: $ zypper install yum-utils $ zypper remove --dry-run `package-cleanup --quiet --leaves` The "--oldkernels" isn't working here though: package-cleanup --oldkernels Setting up yum Traceback (most recent call last): File "/usr/bin/package-cleanup", line 419, in <module> main() File "/usr/bin/package-cleanup", line 388, in main removeKernels(my, opts.kernelcount, opts.confirmed, opts.keepdevel) File "/usr/bin/package-cleanup", line 293, in removeKernels (kver,krel) = runningkernel.split('-') ValueError: too many values to unpack #56: Michael Schröder (mlschroe) (2013-03-11 10:58:37) (reply to #55) There's both "zypper remove --clean deps" and a "unneeded packages" group in YaST. + #57: Christian Kujau (ckujau) (2014-09-21 06:24:30) (reply to #56) + Sorry for the late reply, I haven't used openSUSE in a long time. + "zypper remove --clean deps" is not working in 13.1, as "deps' is not a + package. But "unneeded packages" in YaST works - thanks! + # zypper remove --clean deps + Loading repository data... + Reading installed packages... + 'deps' not found in package names. Trying capabilities. + No provider of 'deps' found. + Resolving package dependencies... + Nothing to do. -- openSUSE Feature: https://features.opensuse.org/300758

1 0