Hello newsgroup,

one of the reasons to change my Linux box to Gentoo is its wonderful
package system.

It's really easy to install new programms or tell Portage to use an
unstable release of any package.

But it seems to be pretty difficult to safely remove some unwanted
software. What I mean is not just removing this special packages but
removing all packages which are dependencies of this certain package and
are now no longer needed. You know, I install this and that programme
just to see how it works or whatever and later on I have loads of
packages in my Gentoo including all their libs...

I would remove the names of that programms from the world file and run
that command that kills every packages that seems not to be used by
anything else but on several web sites I read that this is really
dangerous. So what to do instead?


Daniel Böhmer,
Germany

Daniel Böhmer wrote:

> I would remove the names of that programms from the world file and run
> that command that kills every packages that seems not to be used by
> anything else but on several web sites I read that this is really
> dangerous. So what to do instead?

Well, that *is* the only safe way to do it. *IF* you carefully follow
instructions, you will rarely see any problems, and what little you do
see can usually be corrected with revdep-rebuild. Anyway, here is my
procedure:

1. Run "emerge -DuavN world" (extremely important)
2. Run "emerge -p depclean"
3. Go through the list and do a sanity-check. You could consult your
/var/log/emerge.log to see if a library was installed at roughly the
same time as something you've removed.
4a. Remove them one by one with "emerge -C =category/app-<full version>".
4b. Alternatively, just run "emerge depclean" if you're sure everything
is to be removed.
5. Run "revdep-rebuild -- -p" to check if anything was broken by the
depclean.

This method did fail me spectacularly once when I attempted to forcibly
remove all traces of ESD on my system. It should have been sufficient
to remove the appropriate USE flag and run the procedure, but evidently
it didn't work like it was supposed to. Took a days worth of recompiles
to fully restore.

--
PeKaJe

Xerox never comes up with anything original.

Hello Peter,

thank you for your quick answer! Seems to be of use for me.

> Well, that *is* the only safe way to do it. *IF* you carefully follow
> instructions, you will rarely see any problems, and what little you do
> see can usually be corrected with revdep-rebuild. Anyway, here is my
> procedure:
>
> 1. Run "emerge -DuavN world" (extremely important)

Well, there is an available update for OpenOffice.org which I wanted to
emerge in the next days while I am at school. You know, OOo2 needs about
20 hours to compile on this box (500 Mhz)... And I am not going to take
openoffice-bin or however this binary packages was called. So at this
moment I have outstanding updates but I am not willing to emerge that
now.

Is it really necessary to do *all* updates before removing other stuff?

Beside this there's another problem: I run that first command and got a
list of packages I do not want to emerge. For example the binary ATI
drivers which I installed one day. I removed them from the world file
and an easy "emerge --update world" does ignore it, but the command you
gave me wants to emerge the ATI drivers again. How can I prevent it from
doing so?


Once again thank you for your advice!

Daniel Böhmer

So anyway, it was like, 09:50 CEST May 22 2006, you know? Oh, and, yeah,
Daniel Böhmer was all like, "Dude,

> Is it really necessary to do *all* updates before removing other
> stuff?

If there are specific packages you don't want to upgrade at this time,
you can either do the other updates manually or temporarily mask the
unwanted upgrades in /etc/portage/package.mask.

However, if you manually upgrade packages, I'd advise you to use
the "--oneshot" flag. Otherwise the packages will be added to your
world file if not already there, and having dependancies explicitly
mentioned in world might cause trouble later, if dependancies change.
Best case, you'll have unneeded packages, worst case, you'll get
blockages.

If you choose to temporarily mask versions, make sure you don't forget
to remove the maskings later, and write some comments in the config
files too.

> Beside this there's another problem: I run that first command and
> got a list of packages I do not want to emerge. For example the
> binary ATI drivers which I installed one day. I removed them from
> the world file and an easy "emerge --update world" does ignore it,
> but the command you gave me wants to emerge the ATI drivers again.
> How can I prevent it from doing so?

Unless you unmerged (-C) them as well, they are still on your system.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
10:07:08 up 48 days, 21:01, 8 users, load average: 0.26, 0.18, 0.11
Linux 2.6.16.1 x86_64 GNU/Linux Registered Linux user #261729

Daniel Böhmer wrote:

>> Well, that *is* the only safe way to do it. *IF* you carefully
>> follow instructions, you will rarely see any problems, and what
>> little you do see can usually be corrected with revdep-rebuild.
>> Anyway, here is my procedure:
>>
>> 1. Run "emerge -DuavN world" (extremely important)
>
> Well, there is an available update for OpenOffice.org which I wanted
> to emerge in the next days while I am at school. You know, OOo2 needs
> about 20 hours to compile on this box (500 Mhz)... And I am not going
> to take openoffice-bin or however this binary packages was called. So
> at this moment I have outstanding updates but I am not willing to
> emerge that now.

You know, there is rarely any performance benefit from building OO, as
they disable a lot of optimizations due to a rather fragile build. The
only other major advantage of source compilation is that you mostly
avoid dependency hell. However, this really doesn't matter if you use
the binary package, as it contains everything needed to run. What are
your reasons for preferring the source version?

> Is it really necessary to do *all* updates before removing other
> stuff?

That depends, how well can you handle horrible breakage? There is a
very good reason for the warning. By doing a full upgrade, including
recompiling for changed USE flags, you increase the chances that
everything that may still need the obsolete libraries will work. It may
also catch other kinds of past user errors (like specifying USE flags on
the command line), which may trip you up at depclean time.

At any rate, I forgot an important point on the list in my last post.
If you're going to unmerge something that you think may be important
(basically anything that includes a lib*.so*), first make a backup with
'quickpkg', so you can get a working system back almost instantly, while
you work out what to do about it.

> Beside this there's another problem: I run that first command and got
> a list of packages I do not want to emerge. For example the binary ATI
> drivers which I installed one day. I removed them from the world file
> and an easy "emerge --update world" does ignore it, but the command
> you gave me wants to emerge the ATI drivers again. How can I prevent
> it from doing so?

Well, if a deep upgrade wants to install it, something in the world file
or your combination of USE flags obviously requires it. Try examining
the output of the 'emerge -dDupvN world' command (beware, extreme
verbosity) to see what is requesting it.

> Once again thank you for your advice!

No problem, you're welcome.

--
PeKaJe

Eating chocolate is like being in love without the aggravation.

This is bit offtopic probably... but it is related to OOO2.

On my system I have lprng to deal with printers, which (clearily)
blocks cups system. But strangely openoffice depends on cups while
openoffice-bin does not... that's principally my reason of using
openoffice-bin package

but I was still wondering isn't it possible to get rid of cups?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Jensen wrote:

[snip]
>
> Well, if a deep upgrade wants to install it, something in the world file
> or your combination of USE flags obviously requires it. Try examining
> the output of the 'emerge -dDupvN world' command (beware, extreme
> verbosity) to see what is requesting it.
[snip]

Hi,
Even better:

Add the "t" option to emerge, e.g.

emerge -uatvDN world

This will give you a tree view. Each "root node" (in the leftmost
column) is something directly in your world file. Dependencies are
subnodes in the tree, so you can see what depends on what. Find the
package in question (ATI drivers), then trace the tree up and left
until you hit a root package: that's the entry in WORLD which is
pulling in the drivers. You might remove that package from world, or
you might edit use flags to stop that package (or one of the
intermediate packages) from pulling in the ATI drivers.

Good luck,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdUBG6ZGQ8LKA8nwRAicnAKCZpwhXr1JDu3sjp0upNY rU5eEmbQCeKRes
WIQ85d7zaEx/+yLP6hgUIDI=
=1inD
-----END PGP SIGNATURE-----