[nSLUG] Care and feeding of Gentoo

Donald Teed dteed at artistic.ca
Wed Sep 29 13:40:18 ADT 2004


I've run Gentoo on one of my systems for about a year now,
and I started to notice it was using a little more disk
space on / than expected (/var, /home, /usr/portage are
separate partitions), and so I decided to check into how
to safely use the depclean option to emerge.

I found a good thread on the Gentoo forums, where a
developer 'robmoss' argued against using emerge -U world.
I had been using -U (upgrade, never downgrade) myself
so I checked it out.  He mentioned his recipe for
system maintainance, which went like this (not a script
to execute at once!):

emerge sync
emerge -uDpv world
emerge -uDv world
emerge -pv depclean
emerge -v depclean
revdep-rebuild -pv
revdep-rebuild -v
dispatch-conf

Here is a link to the thread containing his arguments
for using -u rather than -U, and explaining what the above does
(look for the second item from robmoss):

http://forums.gentoo.org/viewtopic.php?t=163377

I learned some additional things related to this process
which may be useful to share with other Gentoo users here.

1. The world file does not have packages added to the world list
    when an ebuild is emerged with a path to the ebuild file.

For several packages I had previously installed, I saw
that 'emerge packagename' would complain that it wasn't
available to stable, and so I would typically cd to the
directory containing the .ebuild file and emerge it with
the ebuild filename as the arg.  This worked fine, except
that it did not add the package name to the world file,
and therefore 'emerge -u world' did not maintain it with
newer versions of those packages.

The better way, is to avoid emerging packages from .ebuild file
names, and use one of several methods to set up the package you
need from unstable or in a particular version, under a
control file in /etc/portage.  The particularly less-than-helpful
aspect of this in Gentoo, is that the basic install does not
even show a /etc/portage directory.  It would be useful
if there were commented out templates for the 5 or 6
types of control files that can reside there.  For more
information on /etc/portage, use 'man portage' .
It isn't complicated, but I would have learned about
it far sooner if there had been the traditional Linux
template for a conf file with some useful comments.
I typically scout out /etc for hints like this.

2. Once the world file is set up to list packages you really want,
the depclean option is useful.  In my case, due to emerging
from .build file names, I captured the output from
emerge -pv depclean | grep '/' and then ran 'qpkg -i' on
package names I did not know.  The important ones were
added onto my world file, and then I tried depclean for real.

3. revdep-rebuild is a very useful tool for locating broken
application and library links.  It attempts to pinpoint which
packages could be emerged to fix any problems.  In some cases
the list of applications to emerge is wrong, because it isn't the
top level application which is missing, but a library file coming
from a dependancy which is actually installed.  In those cases,
the dependancy package needs to be reemerged.

4. I found that 'revdep-rebuild -pv' combined with manually
running emerges was the only reliable way to install packages.
Running 'revdep-rebuild' to let it handle the package
emerging would often result in failed builds.  No idea why.
Even the error from revdep-rebuild hinted that might help.

5. If I was in doubt about a particular package being required
(e.g. all that gnome lib stuff on a KDE box), I would unmerge
the package, and then run 'revdep-rebuild -pv' to see if anything
was broken by the change.  If it did introduce new broken
library links, I would reverse the change and reemerge it.

I spent some time bouncing back and forth between 'revdep-rebuild -pv'
and emerge -C package (remove) or possibly later reemergeing
the package if revdep-rebuild showed broken stuff.

After a day of working on all of my boxes, I now have
no broken library links, no unneeded dependancies, and
they are up to date with deep (-D) emerges of updates
for packages that had "fallen off the map".  Now that
I have a better approach for how to build packages into
Gentoo, it should be little work to maintain them and
also keep the application and dependancy bloat under
control.

--Donald Teed


!DSPAM:415ae575152611530191855!




More information about the nSLUG mailing list