There is no roll back feature that I know of, however, you can check
through the emerge logs to see what order the packages were emerged in
and then run "emerge unmerge <package>" manually for each package you
want to remove.

An easy way to check the emerge logs is to install the package
"genlop" (it was featured in this week's newsletter). Once it's
installed you can run the command "genlop -ul" and it will display a
complete record of the date, time, and version of every package you've
ever installed/uninstalled.

On Tue, 21 Oct 2003 22:51:08 +0200, "Bjørn Halvor Bergtun"
<ask-me@online.nospam.invalid> wrote:

>Sorry for the subject line. Don't know how I accomplished that... (Pun
>intended.)
>
>PipHans wrote:
>> Afaik you are under the mercy of the ebuild...If it explicitly
>> dictates X as a dependancy, then you will get X installed...In theory
>> a correct approach to the issue, but in real life you _will_ come
>> across lousy ebuilds and stuff.
>
>OK. Thanks for clarifying that for me. I was under the impression that
>if I spesified no X, then it wouldn't install X, but alas. Would masking
>known "trouble-packages" help? (E.g. the package invoked by tcltk/tk.
>Thanks to Portnoy for pointing that out.)
>
>> Allways inspect your emerge with a "emerge -p <whatever>" in order to
>> inspect things.
>
>I allways do, but I would hate to get X installed by mistake only
>because I forgot to check one little unimportant package. Does the
>emerge-tool have a rollback-feature for such cases? -As in undoing all
>actions as a ressult of the latest emerge?
>
>> If you are absolutely sure that an ebuild is referencing a rediculous
>> dependancy you could allways edit the ebuild file yourself..and thus
>> avoid things...but be aware that this approach is only for those who
>> really understand the complications of such actions
>
>:P
>It's only a messing-around-for-fun-test-server, so I can afford it.