Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 300758] Show unneeded packages
  • From: fate_noreply@xxxxxxx
  • Date: Tue, 2 Mar 2010 15:55:54 +0100 (CET)
  • Message-id: <feature-300758-123@xxxxxxxxxxxxxx>
Feature changed by: Eduard Huguet (eduardhc)
Feature #300758, revision 123
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.
Requester: Important

openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov)
reject date: 2007-07-17 17:03:57
reject reason: Postponing.
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
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
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.
Requester: Important
Projectmanager: Important

openSUSE-11.3: Evaluation
Requester: Desirable
Projectmanager: Important

Requested by: JP Rosevear (jproseve)

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.


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

#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

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

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

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

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

openSUSE Feature:

< Previous Next >
This Thread