Suppose you want to try out a new package, and it needs a boatload of dependent packages you don't have installed. If you don't like the package and decide to remove it, how do you identify and clean out those now-unnecessary dependencies? You could review your Portage logs to find packages merged just before the main one, but that's a bit tedious. With a little forethought and a couple of one-liner commands, you can easily reverse such trial installations, without struggling to find all the pieces.

Let's use Banshee (a fairly nice media player) as an example. Before installing it, I previewed the result like every good Gentooer:

If I decide I don't want Banshee after all, I can now remove everything installed with it, using just one command:

Remove packages in saved list:

# emerge -aC $(<~/media-sound:banshee.deps)

That's it!

This technique works best if you decide on the fate of such trials fairly soon, before installing other packages whose dependencies overlap. If you can't avoid that, you can use equery and the snapshot file to determine which dependencies to keep. Continuing the example, shortly after installing Banshee I decided to test-drive Beagle as well. The snapshot file for Beagle is:

app-misc:beagle.deps:

=dev-libs/gmime-2.1.19
=app-misc/beagle-0.2.7

I know they are both Mono applications so Beagle must depend on some of the same pieces Banshee pulled in already. The question is, which ones? Easy answer:

(Please note the > in the midst of that command is a shell continuation prompt, not a redirection [don't type it]).

So should I decide to keep Beagle but not Banshee, I would manually excise mono, gtk-sharp, gnome-sharp, glade-sharp and gconf-sharp from media-sound:banshee.deps before using it as input to emerge -aC, and I won't need to run revdep-rebuild afterward.

Actually I've always found it rather worthless--it invariably selects many essential packages for removal. The point here was to locate/record only the deps just installed, not all the deps. If --depclean works for you...I'm envious.

As for dep, IIRC the last time I used it (or maybe its predecessor--it was years ago), it lacked a lot of the power it seems to have now. I'll check it out.

hey, nice work. I was doing something similar (though more manually) until I figured out how to make depclean function. So this might help, I dunno.

depclean needs two things to work:

1. Your world file (/var/lib/portage/world) needs to be complete, with all the packages you've emerged and want installed. You can edit this file manually, or probably safer, just "emerge -n package" anything missing from the world file.

2. Your USE flags need to be set correctly (as in, never running "USE=blah emerge package"). Make sure to set up the global USE variable in /etc/make.conf as well as per package USE flags in /etc/portage/package.use

Also, after you remove anything with depclean, it's a very good idea to run revdep-rebuild (from app-portage/gentoolkit), just to be safe. My routine is now (removing -p after each command if everything looks okay):

Gentoo has been running smoothly since I got my world and use flags in order and started doing this

Same for me. You're absolutely right about the conditions for --depclean to work. I use a slightly different four-step update routine: fis, fiuw, fic, fir. Each one of these commands is an alias entry in my .bashrc:

Why I chose those alias names is out of the scope of this explanation, but has to be with 'fink' in OS X

I've never had a problem with this update/maintenance procedure, and the command names to remember are short and convenient. As a benefit, the procedure eliminates packages you don't need anymore as a dependency when you did nothing special to log them. This is what portage is all about, in the first place. For instance, today I got rid of:

@timeBandit: do u really need that stuff? u can awlays take a look at ur log: ... and search for the package...

Yes of course, and the individual log files in /var/log/portage provide the same info with a simple ls -l. The points of the exercise are (1) not to search at all and (2) save a list for input to emerge to clean the packages.

@vandien and others: I know how to make --depclean work, but it's unusable on my system. I only update world once or twice a year, on average, so depclean rarely understands my dependency graph. Thanks anyway for trying to help. _________________Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

@timeBandit: do u really need that stuff? u can awlays take a look at ur log: ... and search for the package...

Yes of course, and the individual log files in /var/log/portage provide the same info with a simple ls -l. The points of the exercise are (1) not to search at all and (2) save a list for input to emerge to clean the packages.

@vandien and others: I know how to make --depclean work, but it's unusable on my system. I only update world once or twice a year, on average, so depclean rarely understands my dependency graph. Thanks anyway for trying to help.

while this is a very nice hack, having to use sed (or any utility that is not specifically part of portage )to maintain a consistent portage is just silly.

I propose the next revision of Portage includes this functionality some how... so us users don't need to do manual hacks to keep portage clean and clear.

Suppose you want to try out a new package, and it needs a boatload of dependent packages you don't have installed. If you don't like the package and decide to remove it, how do you identify and clean out those now-unnecessary dependencies?

Someone mentioned a utility called demerge - It's awesome; It sortof takes a snapshot of the state of Portage, so you can try a bunch of stuff, then make it revert back to that state by 'intelligently' unmerging and re-merging anything that was added/removed