I believe including a dependency ability into portage (at least using a switch
if you really want it) would be nice. If you remove a component, and you want
to know if it is needed by anything, then portage could tell you.
As it stands right now, you can remove a major component of a working item
and render it destroyed without even realizing it.
Changing to normal priority considering the alternatives that have become
available via the forum.
Is it possible someone could round up all of the suggestions from the forum and
post them as a sticky item in the Newbies or Portage forum? Then, the FAQ could
point to it because this is a feature I'd really like to see, but I'm fine with
using scripts for now. I think Newbies would like a really easy place to find
Suggestion: implement reverse dependency tracking using reference counts:
every package has a reference counter indicating how many packages that depend
on it are installed. Whenever reference count for a package is 0, it will be
Maybe extra feature: at the end of the "dependency chain" the reference count is
inherently always 0, which means that end-user applications will always be
automatically removed. To avoid this, we could have a flag indicating that it is
an end user app.
*** Bug 4227 has been marked as a duplicate of this bug. ***
*** Bug 10740 has been marked as a duplicate of this bug. ***
Implementation suggestion: add a new command to emerge called
"depunmerge." The user would type "emerge depunmerge
<package>" to unmerge with dependencies. Portage would simulate
the removal of the package (temporarily remove it from the
package database) and then look at each package and see if it
has missing dependencies. If it's dependencies are not there, then
this package must be removed as well. If more packages are removed,
portage does another loop to see if more packages will have missing
dependencies because of these new removals, and so on until there
are no more missing dependencies.
This is just a suggestion, of course.
qpkg provides -q ...
-q, --query-deps display all installed packages
depending on selected packages
The dependency ability of qpkg -q is not sufficient, mostly because it is not recursive. For example:
$ qpkg -I -q python-2.2.3-r1
DEPENDED ON BY:
$ qpkg -I -q libxml2-2.5.8
DEPENDED ON BY:
As you can see, all the packages in the second listing should have also been in the first, because they indirectly depend on python (they depend on libxml2, which depends on python).
In addition, can this functionality be included in emerge --unmerge?
*** Bug 32303 has been marked as a duplicate of this bug. ***
Is there still interest in getting this functionality? I've been working on a patch to do this; see http://forums.gentoo.org/viewtopic.php?t=210288 for info (check down for the latest version of the patch). It seems to be working properly in most cases now, and I'd appreciate feedback. ;)
Can you attach a unified diff here please? There is still interest. It's on my TODO list. ;)
Created attachment 37600 [details, diff]
Unified diff against 2.0.51_pre20
Created attachment 39666 [details, diff]
Implements revdeps in vardbapi
Adds a revdeps() method to portage.vardbapi; carpaski suggested this was a
better way to do things.
I think something that works in the other direction too would be usefull, something like emerge unmerge --deep <package> that would unmerge all unneded dependencies of the package we are unmerging. This would make unmerging monsters like Gnome that install 100+ dependencies much smoother.
I also like to be able to list package that are not dependencies of anything else.
these packages should be end program and the list should be <= world
good way to clean up what you dont need.
Yeah, basically a gentoo version of deborphan. That would be nice.
Of course, it should also show unused libs, not just apps.
*** Bug 97946 has been marked as a duplicate of this bug. ***
*** Bug 100379 has been marked as a duplicate of this bug. ***
*** Bug 43902 has been marked as a duplicate of this bug. ***
Portage of the actual version also has a problem with updates that is dependend
from such a "package-dependency" function.
you emerged kde. Kde is in the world file now.
And kde needs a component. You later unmerge kde because you don't need it
anymore, but the component installed with, is not unmerged. This is right for
you, since you want to use this component sometimes.
But this component was installed as a dependency, it is not in the world file
and does not get updated with emerge -uD world.
This behaviour is described, for example, in the last post of bug 100527 which,
of course, is related to other update problems.
I wonder how much gentoo users out there have a pretty old system and do not
If portage would have more information about packaged installed, such
misbehaviour could be cured.
*** Bug 51412 has been marked as a duplicate of this bug. ***
Hello, I made a small script "fixing" that problem
Have fun with it :-)
/usr/bin/emerge -avC $1 `equery depends $1 -D |grep --invert-match Searching |
grep --invert-match \* | grep --invert-match done`;
# Written by Florian Mayer(aka name) ;)
Thats the whole source :)
If my webspace is down out you can still download the script :)
Can someone on this bug that doesn't already have w3m test this: ?
1. emerge w3m
On my system, the following packages are merged:
[ebuild N ] www-client/w3m-0.5.1-r3 USE="X async gpm gtk imlib nls ssl unicode xface -fbcon -lynxkeymap -migemo" 0 kB
[ebuild N ] media-libs/compface-1.5.2 0 kB
[ebuild N ] dev-libs/boehm-gc-6.5 USE="threads -nocxx" 0 kB
unmerge (as according to Florian's script) w3m
for me, it gave very shocking results - the system asked me if I wanted to unmerge gentoo-sources, kdelibs and hal, for example
Afaik this requires a VDB change, at least you need to record which atom you picked out of the || ( A B ) so that portage doesn't have to guess at unmerge time. You also need to store the refcounts of course ;)
(In reply to comment #26)
> Afaik this requires a VDB change, at least you need to record which atom you
> picked out of the || ( A B ) so that portage doesn't have to guess at unmerge
> time. You also need to store the refcounts of course ;)
Isn't it possible that the package satisfying an || ( A B ) dep could change over time? If so, why not just find evaluate which package satisfies the dep on the fly? That's basically that way that depclean works. It finds all the packages that no longer have any references. The new depclean implementation (from bug 67179) is pretty quick too, even on my system that has 1600+ packages installed.
*** Bug 154160 has been marked as a duplicate of this bug. ***
The --depclean implementation is fast emough in recent versions of portage that we can use it to make --unmerge do the reverse dependency check by default (and allow the user to override it with --nodeps). It's just a matter of generalizing the code so that it's usable for both --unmerge and --depclean (or else write a similar but separate implementation for --unmerge).
Created attachment 125536 [details, diff]
allow --depclean accept atoms and act like a safe version of --unmerge
This implements the requested feature as an extension of --depclean. Just give it a list of atoms like you would with --unmerge. With --verbose, it will display reverse dependencies. The patch also makes --prune safe (use --nodeps if you want to ignore reverse dependencies).
This has been released in 2.1.3_rc9.