Mailinglist Archive: opensuse-features (503 mails)

< Previous Next >
[openFate 300758] Show orphaned packages
  • From: fate_noreply@xxxxxxx
  • Date: Sun, 18 Jan 2009 01:36:29 +0100 (CET)
  • Message-id: <feature-300758-41@xxxxxxxxxxxxxx>
Feature changed by: Rémy Marquis (Spyhawk)
Feature #300758, revision 41
Title: Show orphaned packages

openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk@xxxxxxxxxx>
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@xxxxxxxxxx>
reject date: 2007-07-17 17:03:57
reject reason: Postponing.
Requester: Important
Projectmanager: Desirable

openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov@xxxxxxxxxx>
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@xxxxxxxxxx>
reject date: 2008-07-07 13:34:02
reject reason: Postponing, needs underlaying infrastructure to be fixed
Requester: Important

openSUSE-11.2: Evaluation
Requester: Important

Requested by: Stephan Binner (beineri)
Interested: Andreas Jaeger (a_jaeger)
Interested: Andrey S (seld)
Interested: Ján Kupec (jkupec)
Interested: Matthias Eckermann (mge1512)
Interested: Pedro Canovas (pedrogeek)
+ Interested: Rémy Marquis (spyhawk)
Interested: Ruchir Brahmbhatt (ruchir)
Interested: Santiago Hirschfeld (jsantiagoh)
Interested: Stefan Ott (steve_odd)
Interested: Vincent Untz (vuntz)
Partner organization:

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.


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

openSUSE Feature:

< Previous Next >
This Thread