en/handbook/hb-working-portage.xml

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->

<!-- $Header: /home/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.4 2003/11/27 11:08:00 swift Exp $ -->

<sections>
<section>
<title>Obtaining Package Information</title>
<subsection>
<title>The Lord of All Tools: emerge</title>
<body>

<p>
The main Portage tool that most users will use is <c>emerge</c>. We have already
used it during the Gentoo installation and in the previous chapter, but we just
briefly explained how to use it. This chapter will elaborate on <c>emerge</c>
and learn you how to use <c>emerge</c> to fix all your software-related needs.
</p>

<p>
<c>emerge</c> is the command used to install, remove, query and maintain
software packages. It is a front-end for <c>ebuild</c>; people interested in
becoming Gentoo professionals will learn how to use <c>ebuild</c> later on. For
now, we will focus on <c>emerge</c> as it has functionality that <c>ebuild</c>
lacks (such as resolving dependencies, searching the Portage tree, etc.).
</p>

<p>
Since <c>emerge</c> is the most important tool for Gentoo users, it has an
extensive manpage you can read by issuing <c>man emerge</c>. You can also view
the in-command help by running <c>emerge --help</c>.
</p>

<pre caption="Retrieving help for emerge">
# <i>man emerge</i>
# <i>emerge --help</i>
</pre>

</body>
</subsection>
<subsection>
<title>The Portage Tree</title>
<body>

<p>
Before we continue describing <c>emerge</c>, let us first take a look at the
Portage Tree. Go to <path>/usr/portage</path> and do a listing of the available
directories.
</p>

<pre caption="Viewing the Portage Tree">
# <i>cd /usr/portage; ls --classify</i>
<comment>(The --classify will append a special character to note the filetype)</comment>
app-admin/       dev-ml/            gnome-libs/     net-print/
app-arch/        dev-perl/          gnome-office/   net-wireless/
app-benchmarks/  dev-php/           header.txt      net-www/
app-cdr/         dev-python/        incoming/       net-zope/
app-crypt/       dev-ruby/          jython/         packages/
app-dicts/       dev-tcltk/         kde-apps/       profiles/
app-doc/         dev-tex/           kde-base/       releases/
app-editors/     dev-util/          kde-i18n/       scripts/
app-emacs/       distfiles/         kde-libs/       sec-policy/
app-emulation/   eclass/            licenses/       skel.ChangeLog
app-games/       experimental/      media-fonts/    skel.ebuild
app-gnustep/     files/             media-gfx/      skel.metadata.xml
app-i18n/        fresco-base/       media-libs/     snapshots/
app-misc/        games-action/      media-plugins/  sys-apps/
app-office/      games-arcade/      media-radio/    sys-build/
app-pda/         games-board/       media-sound/    sys-cluster/
app-portage/     games-emulation/   media-tv/       sys-devel/
app-sci/         games-engines/     media-video/    sys-fs/
app-shells/      games-fps/         metadata/       sys-kernel/
app-text/        games-kids/        net-analyzer/   sys-kmods/
app-vim/         games-misc/        net-apache/     sys-libs/
app-xemacs/      games-mud/         net-dialup/     unix2tcp/
berlin-base/     games-puzzle/      net-dns/        x11-base/
dev-ada/         games-roguelike/   net-firewall/   x11-libs/
dev-cpp/         games-rpg/         net-fs/         x11-misc/
dev-db/          games-server/      net-ftp/        x11-plugins/
dev-dotnet/      games-simulation/  net-im/         x11-terms/
dev-embedded/    games-sports/      net-irc/        x11-themes/
dev-games/       games-strategy/    net-libs/       x11-wm/
dev-haskell/     games-util/        net-mail/       xfce-base/
dev-java/        glep/              net-misc/       xfce-extra/
dev-lang/        gnome-apps/        net-nds/
dev-libs/        gnome-base/        net-news/
dev-lisp/        gnome-extra/       net-p2p/
</pre>

<p>
As you can see, the Portage tree has several subdirectories. Most of them are
the <e>categories</e> in which the Gentoo packages, called <e>ebuilds</e>,
reside. Take a look at, for instance, <path>app-office</path>:
</p>

<pre caption="Viewing a category">
# <i>cd app-office; ls --classify</i>
abiword/     gnotime/   kmymoney2/  ooodi/              plan/     timestamp.x
dia/         gnucash/   koffice/    oooqs/              qhacc/
dia2code/    gnumeric/  lxbank/     openoffice/         sc/
facturalux/  ical/      lyx/        openoffice-bin/     scribus/
gaby/        kbudget/   mdbtools/   openoffice-ximian/  siag/
gnofin/      khacc/     mrproject/  phprojekt/          texmacs/
</pre>

<p>
Inside a category you will find the packages belonging to that category, with a
seperate directory for each package. Let us take a look at the <c>openoffice</c>
package:
</p>

<pre caption="Viewing a package">
# <i>cd openoffice; ls --classify</i>
ChangeLog  files/        openoffice-1.0.3-r1.ebuild  openoffice-1.1.0-r2.ebuild
Manifest   metadata.xml  openoffice-1.1.0-r1.ebuild  openoffice-1.1.0.ebuild
</pre>

<p>
Remember that we told you that a Gentoo package is called an ebuild? Well, in
the example directory four of such ebuilds are stored. Their naming is
almost identical: they only differ in the version name.
You are free to view the contents of such a package: they are plain scripts. We
will not discuss it right now as it isn't important to know if you plan on just
using Gentoo.
</p>

<p>
The other files are the <path>ChangeLog</path> (which contains a listing of all
the changes done to the ebuilds), <path>Manifest</path> (which contains the
checksums and permissions of all the files in the directory) and
<path>metadata.xml</path> (which contains more information about the package,
such as the responsible development group -- called <e>herd</e> and a more
extensive description).
</p>

<p>
Inside the <path>files</path> directory you will find extra files, needed by
Portage: digests (checksums and permissions of the files needed by a single
version of the package), patches, example configuration files, etc.
</p>

<pre caption="Viewing the extra files">
# <i>cd files; ls --classify</i>
1.0.3/  digest-openoffice-1.0.3-r1  digest-openoffice-1.1.0-r1
1.1.0/  digest-openoffice-1.1.0     digest-openoffice-1.1.0-r2
# <i>cd 1.1.0; ls --classify</i>
fixed-gcc.patch      ooffice-wrapper-1.3
newstlportfix.patch  openoffice-1.1.0-linux-2.6-fix.patch
no-mozab.patch       openoffice-1.1.0-sparc64-fix.patch
nptl.patch
</pre>

<p>
If you go back to the root of the Portage tree (<path>/usr/portage</path>) you
will notice that there are other, non-category directories too. We will discuss
those later in this chapter. 
</p>

</body>
</subsection>
<subsection>
<title>Search for a Package</title>
<body>

<p>
If you are new to Linux or Gentoo, you might not know what tool you need for
what job. To facilitate searching, <c>emerge</c> provides you with a way to
search through the available packages on your system. There are two ways you can
search through packages: by <e>name</e>, or by <e>name</e> and 
<e>description</e>.
</p>

<p>
To search through the Portage tree by name, use <c>emerge search</c>. For
instance, to find out more about <c>mozilla</c>:
</p>

<pre caption="Showing information about mozilla">
# <i>emerge search mozilla</i>
Searching...   
[ Results for search key : mozilla ]
[ Applications found : 5 ]
<comment>(Some output removed to improve readability)</comment>
*  net-www/mozilla
      Latest version available: 1.5-r1
      Latest version installed: 1.4-r3
      Size of downloaded files: 29,153 kB
      Homepage:    http://www.mozilla.org
      Description: The Mozilla Web Browser

*  net-www/mozilla-firebird
      Latest version available: 0.7
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 37,850 kB
      Homepage:    http://www.mozilla.org/projects/firebird/
      Description: The Mozilla Firebird Web Browser
<comment>(...)</comment>
</pre>

<p>
If you want to include a search through the descriptions too, use the
<c>--searchdesc</c> argument:
</p>

<pre caption="Search through the descriptions too">
# <i>emerge --searchdesc mozilla</i>
Searching...   
[ Results for search key : mozilla ]
[ Applications found : 10 ]
<comment>(Some output removed to improve readability)</comment>
*  dev-libs/nss-3.8
      Latest version available: 3.8
      Latest version installed: 3.8
      Size of downloaded files:  2,782 kB
      Homepage:    http://www.mozilla.org/projects/security/pki/nss/
      Description: Mozilla's Netscape Security Services Library that implements PKI support
</pre>

<p>
As you can see, the output of <c>emerge</c> informs you about the category and
name of the package, the available version, the currently installed version, 
the size of the downloaded files, the homepage and the small description.
</p>

<p>
You see something new? Yes, <e>downloaded files</e>. When you tell Portage to
install a package, it of course needs to have the necessary sources (or
precompiled packages) available. It therefor checks the contents of
<path>/usr/portage/distfiles</path> (for sourcecode) or
<path>/usr/portage/packages/All</path> (for precompiled packages) to see if the
necessary files are already available. If not, it downloads the necessary files
and places them in those directories.
</p> 

<note>
Searching the Portage Tree, especially when using <c>--searchdesc</c>, is very
time consuming. There are other, more performant tools available. We will
describe those in the chapter on <uri link="?part=2&amp;chap=7">Gentoolkit and
Other Tools</uri>.
</note>

</body>
</subsection>
<subsection>
<title>Viewing the ChangeLog</title>
<body>

<p>
While browsing through the Portage Tree, you saw that there was a ChangeLog for
each package. You can view this ChangeLog with <c>emerge</c> too. Use the
<c>--pretend --changelog</c> (<c>-pl</c> in short) options. As an example we
will view the ChangeLog entries for <c>gnumeric</c>:
</p>

<pre caption="Viewing the ChangeLog entries for gnumeric">
# <i>emerge --pretend --changelog gnumeric</i>
</pre>

</body>
</subsection>
</section>
<section>
<title>Updating Portage</title>
<subsection>
<title>Introduction</title>
<body>

<p>
Searching through Portage is nice, but if you don't update your Portage Tree
regularly, you will be stuck with the packages and versions available on your
system. This means that your system will get outdated pretty soon, and that
packages with possible security problems will remain on your system.
</p>

<p>
There are several ways to update your Portage Tree. The most popular method is
by using one of our <uri link="/main/en/mirrors.xml">rsync mirrors</uri>.
Another one is by using a Portage snapshot (in case a firewall or unavailability
of a network prohibits the use of the rsync server).
</p>

</body>
</subsection>
<subsection>
<title>Selecting a Mirror for rsync</title>
<body>

<p>
It is adviseable to first select a fast <uri
link="/main/en/mirrors.xml">mirror</uri> close to you. You can do this manually
(by setting the <c>SYNC</c> variable in <path>/etc/make.conf</path>) or use
<c>mirrorselect</c> to do this for you automatically. As the <c>SYNC</c>
variable will be discussed later on, we will focus on using <c>mirrorselect</c>.
First install <c>mirrorselect</c> by emerging it:
</p>

<pre caption="Installing mirrorselect">
# <i>emerge --usepkg mirrorselect</i>
</pre>

<p>
Now run <c>mirrorselect</c> to automatically select mirrors for you (it will
also setup Portage to use a mirror for the sourcecode):
</p>

<pre caption="Running mirrorselect">
# <i>mirrorselect -a -s3</i>
</pre>

</body>
</subsection>
<subsection>
<title>Updating Portage</title>
<body>

<p>
To update Portage using rsync, simply run <c>emerge sync</c>:
</p>

<pre caption="Updating Portage using emerge sync">
# <i>emerge sync</i>
</pre>

<p>
If this fails (due to network problems, or a firewall), you can try using
<c>emerge-webrsync</c> which will download a Portage Tree snapshot using
<c>wget</c>. This also means that you can use proxies if you want. We discussed
how to setup your system to use proxies during the Gentoo installation.
</p>

<pre caption="Updating Portage using emerge-webrsync">
# <i>emerge-webrsync</i>
</pre>

</body>
</subsection>
</section>
<section>
<title>Maintaining Software</title>
<subsection>
<title>Building or Prebuild?</title>
<body>

<p>
Gentoo provides ebuilds, the Gentoo packages if you like. But when you want to
install such an ebuild, you can choose between <e>building</e> the package, or
using a <e>prebuild</e> package. But what are the advantages/disadvantages of
both approaches, and can they be used next to each other?
</p>

<p>
As you probably have guessed, building packages takes a lot of time (especially
if you have little resources or want to build big packages, such as <uri
link="http://www.kde.org">KDE</uri>, <uri
link="http://www.openoffice.org">OpenOffice.org</uri>, etc.). By building the
package, you can use the <c>USE</c> setting to tweak the package to your system.
Of course, you can also define high optimization options (in the <c>CFLAGS</c> 
and <c>CXXFLAGS</c> variables) to compile the package with.
</p>

<p>
Using prebuild packages improves the installation time (as no more compilation
is needed), but you will lose the advantages of the <c>USE</c> setting and the
<c>CFLAGS</c> &amp; <c>CXXFLAGS</c> variables.
</p>

<p>
As previously stated, prebuild packages are stored in the
<path>/usr/portage/packages/All</path> directory, while the sourcecode of the
packages are placed in <path>/usr/portage/distfiles</path>. If you have finished
installing a package you can remove the package or sourcecode from the
respective directory. However, you might want to keep the package/sourcecode of
the latest version, just in case you want to reinstall the package (so you don't
have to redownload it).
</p>

</body>
</subsection>
<subsection>
<title>Installing Software from Sources</title>
<body>

<p>
Okay, enough talking, let's cut to the chase. To install a package, you will use
the <c>emerge</c> command. If you don't want to use any prebuild packages, you
can just use <c>emerge &lt;package-name&gt;</c> or <c>emerge
&lt;category&gt;/&lt;package-name&gt;</c>. As an example we'll install
<c>gnumeric</c>:
</p>

<pre caption="Building gnumeric">
# <i>emerge gnumeric</i>
</pre>

<p>
This will download the sourcecode for you and unpacks, compiles and installs the
package on your system. It will also do the same for all the dependencies. If
you want to see what dependencies will be installed with it, use the
<c>--pretend</c> option (<c>-p</c> in short):
</p>

<pre caption="Pretending to build gnumeric">
# <i>emerge --pretend gnumeric</i>
</pre>

<p>
If you want to download the sourcecode of the package and its dependencies, 
but don't want to build the package, use the <c>--fetchonly</c> option 
(<c>-f</c> in short):
</p>

<pre caption="Fetching sources for gnumeric">
# <i>emerge --fetchonly gnumeric</i>
</pre>

<p>
If you want to see where <c>emerge</c> downloads the sources from, combine the
<c>--fetchonly</c> and <c>--pretend</c> options:
</p>

<pre caption="Showing URLs of the sources for gnumeric">
# <i>emerge --fetchonly --pretend gnumeric</i>
</pre>

<p>
You can also opt to install a specific version of a package.
For instance, if you want to install a gnumeric version older than 1.2 -- for
any reason whatsoever :) you would type:
</p>

<pre caption="Installing a specific gnumeric version">
# <i>emerge "&lt;gnumeric-1.2"</i>
</pre>

<p>
Other possibilities are of course "&gt;" (later version) and "=" (the exact
version).
</p>

</body>
</subsection>
<subsection>
<title>Installing Prebuild Packages</title>
<body>

<p>
When you want to install a prebuild package, you should use the <c>--usepkg</c>
option (<c>-k</c> in short). This will use the binary package available in
<path>/usr/portage/packages/All</path> <e>if</e> the package and the version of
the application you want to install match.
</p>

<pre caption="Installing a prebuild package for gnumeric">
# <i>emerge --usepkg gnumeric</i>
</pre>

<p>
If you want to use the binary package, even if the versions don't match, use
<c>--usepkgonly</c> (<c>-K</c> in short).
</p>

<pre caption="Installing the prebuild package for gnumeric">
# <i>emerge --usepkgonly gnumeric</i>
</pre>

<!-- TODO When handbook goes life, comment out this parts until the mirrors have
     been updated with online GRP packages. -->
<p>
If you don't have the prebuild package on your system yet, you can have
<c>emerge</c> download it from a mirror, defined in the <c>PORTAGE_BINHOST</c>
variable declared in <path>/etc/make.conf</path>.
</p>

<p>
To download the binary package in case this package doesn't exist on
your system already, use <c>--getbinpkg</c> (<c>-g</c> in short):
</p>

<pre caption="Downloading and installing a prebuild package for gnumeric">
# <i>emerge --getbinpkg gnumeric</i>
</pre>

<p>
This will download the package and the package-related information for you and 
install it on your system, together with the dependencies. If you want to see 
what dependencies will be installed with it, use the <c>--pretend</c> option 
(<c>-p</c> in short):
</p>

<pre caption="Pretending to download the prebuild packages for gnumeric">
# <i>emerge --ginbinpkg --pretend gnumeric</i>
</pre>

<p>
You can also opt to download the prebuild package (and the package-related
information) <e>without</e> checking the information on your local system and
<e>without</e> using the prebuild package already on your system (if
applicable), use the <c>--getbinpkgonly</c> option (<c>-G</c> in short):
</p>

<pre caption="Installing a prebuild package without using local information">
# <i>emerge --getbinpkgonly gnumeric</i>
</pre>

<!-- TODO Up until here -->

<p>
You can also opt to install a specific version of a package.
For instance, if you want to install a gnumeric version older than 1.2 -- for
any reason whatsoever :) you would type:
</p>

<pre caption="Installing a specific gnumeric version">
# <i>emerge --usepkg "&lt;gnumeric-1.2"</i>
</pre>

<p>
Other possibilities are of course "&gt;" (later version) and "=" (the exact
version).
</p>


</body>
</subsection>
<subsection>
<title>Updating your System</title>
<body>

<p>
Portage knows two special tags to denote a set of software packages:
<e>system</e> and <e>world</e>. You have already seen the former while 
installing Gentoo if you didn't use a <e>stage3</e> installation. To refresh
things: <e>system</e> is the collection of <e>core</e> packages, necessary to
have a working Gentoo system.
</p>

<p>
The <e>world</e> tag consists of all software you have installed yourself on
your system plus the <e>system</e> information. In other words, every time you
emerge a package using <c>emerge &lt;package-name&gt;</c>, the
<c>&lt;package-name&gt;</c> is registered in the <e>world</e> file
(<path>/var/cache/edb/world</path>). Dependencies are <e>not</e> part of the
<e>world</e> file, but we will get to that later.
</p>

<p>
If you want to update the system packages, use the <c>--update</c> option
(<c>-u</c> in short):
</p>

<pre caption="Updating the system packages">
# <i>emerge --update system</i>
</pre>

<p>
An identical approach can be used for the world packages:
</p>

<pre caption="Updating your entire system">
# <i>emerge --update world</i>
</pre>

<p>
Again, if you want to see what <c>emerge</c> wants to update, use the
<c>--pretend</c> option together with the <c>--update</c> option:
</p>

<pre caption="Pretending to update your entire system">
# <i>emerge --pretend --update world</i>
<comment>(Some output removed to improve readability)</comment>
[ebuild     U ] net-misc/wget-1.9-r1 [1.9] 
[ebuild     UD] media-video/dvdauthor-0.5.0 [0.5.3] 
[ebuild     U ] net-analyzer/ethereal-0.9.16 [0.9.14] 
</pre>

<p>
Right next to the word "ebuild" you will notice a letter (or combination of
letters) which gives you more information about the package:
</p>

<ul>
  <li>
    <e>B</e> (blocks) The package listed to the left is blocking the emerge of
    the package listed to the right
  </li>
  <li>
    <e>N</e> (new) The package is new to your system and will be emerged for the
    first time
  </li>
  <li>
    <e>R</e> (reemerge) The package isn't new, but needs to be reemerged
  </li>
  <li>
    <e>F</e> (fetch) The package requires that you download the sourcecode
    manually (for instance due to licencing issues)
  </li>
  <li>
    <e>U</e> (update) The package already exists on your system but will be
    upgraded
  </li>
  <li>
    <e>UD</e> (downgrade) The package already exists on your system but will be
    downgraded
  </li>
  <li>
    <e>U-</e> (slot warning) The package you have installed on your system
    is listed as a package that can not coexist with a different version, but
    your update does. The update will be installed and the older version will be
    removed.
  </li>
</ul>

<p>
In certain cases, an update may mean a downgrade (i.e. install an older version
instead of a newer version). If you don't want this to happen, use the
<c>--upgradeonly</c> option (<c>-U</c> in short):
</p>

<pre caption="Upgrading your entire system">
# <i>emerge --update --upgradeonly world</i>
</pre>

<p>
Of course, we are talking here about <e>system</e> and <e>world</e>, but you can
perform the same actions for individual software packages.
</p>

</body>
</subsection>
<subsection>
<title>Removing Software</title>
<body>

<p>
If you want to remove software from your system, you can use the <c>unmerge</c>
option (<c>-C</c> - capital C - in short):
</p>

<pre caption="Uninstalling software">
# <i>emerge unmerge gnumeric</i>
</pre>

<p>
If you want to test a removal (but not perform it), you can use <c>--pretend</c>
again:
</p>

<pre caption="Pretending to uninstall software">
# <i>emerge --pretend unmerge gnumeric</i>
</pre>

<warn>
Portage doesn't verify if a package is a dependency for another
installed package. It also doesn't warn you if the package is part of
<e>system</e>, i.e. a core application necessary for the correct functioning of
your system!
</warn>

</body>
</subsection>
</section>
<section>
<title>Software Availability</title>
<subsection>
<title>ARCH or not?</title>
<body>

<p>
Gentoo places its packages in two possible stadia called <e>ARCH</e> and
<e>~ARCH</e>. Don't take this literally: the stadia depend on the architecture
you are using. In other words, for x86-based systems you have <e>x86</e> and
<e>~x86</e>, for ppc-based systems you have <e>ppc</e> and <e>~ppc</e> etc.
</p>

<p>
The <e>~ARCH</e> stadium means that the package works for the developer in
charge of the package, but that the package hasn't been tested thoroughly enough
by the community to be placed in <e>ARCH</e>. <e>~ARCH</e> packages usually go
to <e>ARCH</e> after being bugfree for a sufficient amount of time.
</p>

<p>
Your system will use <e>ARCH</e> packages per default. If you want to live on
the edge, don't mind having a broken package once in a while, and you like
submitting bugreports to <uri
link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, then you can opt to use
<e>~ARCH</e> packages. To "move" your system to a <e>~ARCH</e>-using system,
edit the <c>ACCEPT_KEYWORDS</c> variable in <path>/etc/make.conf</path> so that
it reads <e>~ARCH</e> (again: for x86-based systems: <e>~x86</e>, etc.).
</p>

<p>
If you want to update your system now, you will notice that <e>a lot</e> of
packages will be updated!
</p>

</body>
</subsection>
<subsection>
<title>Masked Packages</title>
<body>

<p>
When you want to install a package, you might come across the following message:
</p>

<pre caption="Message about masked packages">
Calculating dependencies   
!!! <comment>all ebuilds that could satisfy </comment>&lt;your package&gt;<comment> have been masked.</comment>
</pre>

<p>
A package can be masked due to two reasons: 
</p>

<ol>
  <li>The package is in <e>~ARCH</e> while you use <e>ARCH</e></li>
  <li>The package is hard-masked explicitly</li>
</ol>

<p>
If the package is masked because of the first reason, and you <e>really</e> want
to install it (knowing that there <e>is</e> a reason why it isn't available in
<e>ARCH</e>), you can temporarily accept <e>~ARCH</e> packages:
</p>

<pre caption="Temporarily accepting ~ARCH packages">
# <i>ACCEPT_KEYWORDS="~x86" emerge gnumeric</i>
</pre>

<p>
A package is hardmasked if it is listed in
<path>/usr/portage/profiles/package.mask</path>. If you read this file, you
will also read the reason why the package is hardmasked (it is usually added as
a comment). If you want to install the package nevertheless (despite all the
possible warnings we could ever throw at your head about "breaking your system",
"breaks other packages", or "badly needs testing"), create the
<path>/etc/portage/package.unmask</path> file and list the package in it (use
the same format as is used in <path>/usr/portage/profiles/package.mask</path>).
</p>

<p>
Do <e>not</e> alter the <path>/usr/portage/profiles/package.mask</path> file as
all changes are undone the next time you update your Portage tree.
</p>

<p>
Another trick to circumvent the "masked package" problem is to install the
package using the full path. This will ignore both the <c>ACCEPT_KEYWORD</c> 
settings and the <path>package.mask</path> listing.
</p>

<pre caption="Installing a package without checking for stadium / masking">
# <i>emerge /usr/portage/app-office/gnumeric/gnumeric-1.2.0.ebuild</i>
</pre>

</body>
</subsection>
<subsection>
<title>Blocked Packages</title>
<body>

<p>
You have a situation when you receive the following error on your screen:
</p>

<pre caption="Blocking package">
[blocks B     ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0) 
</pre>

<p>
In the above example, the package <c>bonobo-activation</c> is blocking the
emerge of <c>libbonobo</c>. To resolve this issue, remove the
<c>bonobo-activation</c> package and continue:
</p>

<pre caption="Resolving a blocking situation">
# <i>emerge unmerge bonobo-activation</i>
</pre>

</body>
</subsection>
</section>
</sections>