| 1 |
swift |
1.18 |
<?xml version='1.0' encoding='UTF-8'?> |
| 2 |
|
|
<!DOCTYPE sections SYSTEM "/dtd/book.dtd"> |
| 3 |
|
|
|
| 4 |
swift |
1.1 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 5 |
|
|
<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> |
| 6 |
|
|
|
| 7 |
neysx |
1.33 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.32 2004/08/21 18:08:12 swift Exp $ --> |
| 8 |
swift |
1.1 |
|
| 9 |
|
|
<sections> |
| 10 |
|
|
<section> |
| 11 |
|
|
<title>Obtaining Package Information</title> |
| 12 |
|
|
<subsection> |
| 13 |
|
|
<title>The Lord of All Tools: emerge</title> |
| 14 |
|
|
<body> |
| 15 |
|
|
|
| 16 |
swift |
1.2 |
<p> |
| 17 |
swift |
1.5 |
The main Portage tool that most users will use is <c>emerge</c>. We have already |
| 18 |
|
|
used it during the Gentoo installation and in the previous chapter, but we just |
| 19 |
|
|
briefly explained how to use it. This chapter will elaborate on <c>emerge</c> |
| 20 |
swift |
1.13 |
and teach you how to use <c>emerge</c> to fix all your software-related needs. |
| 21 |
swift |
1.2 |
</p> |
| 22 |
|
|
|
| 23 |
|
|
<p> |
| 24 |
|
|
<c>emerge</c> is the command used to install, remove, query and maintain |
| 25 |
|
|
software packages. It is a front-end for <c>ebuild</c>; people interested in |
| 26 |
|
|
becoming Gentoo professionals will learn how to use <c>ebuild</c> later on. For |
| 27 |
|
|
now, we will focus on <c>emerge</c> as it has functionality that <c>ebuild</c> |
| 28 |
|
|
lacks (such as resolving dependencies, searching the Portage tree, etc.). |
| 29 |
|
|
</p> |
| 30 |
|
|
|
| 31 |
|
|
<p> |
| 32 |
|
|
Since <c>emerge</c> is the most important tool for Gentoo users, it has an |
| 33 |
|
|
extensive manpage you can read by issuing <c>man emerge</c>. You can also view |
| 34 |
|
|
the in-command help by running <c>emerge --help</c>. |
| 35 |
|
|
</p> |
| 36 |
|
|
|
| 37 |
|
|
<pre caption="Retrieving help for emerge"> |
| 38 |
|
|
# <i>man emerge</i> |
| 39 |
|
|
# <i>emerge --help</i> |
| 40 |
|
|
</pre> |
| 41 |
|
|
|
| 42 |
|
|
</body> |
| 43 |
|
|
</subsection> |
| 44 |
|
|
<subsection> |
| 45 |
|
|
<title>The Portage Tree</title> |
| 46 |
|
|
<body> |
| 47 |
|
|
|
| 48 |
|
|
<p> |
| 49 |
|
|
Before we continue describing <c>emerge</c>, let us first take a look at the |
| 50 |
|
|
Portage Tree. Go to <path>/usr/portage</path> and do a listing of the available |
| 51 |
swift |
1.6 |
directories. We use <c>ls --classify</c> to list the contents of a |
| 52 |
|
|
directory as it will show directories with a trailing "/". |
| 53 |
swift |
1.2 |
</p> |
| 54 |
|
|
|
| 55 |
|
|
<pre caption="Viewing the Portage Tree"> |
| 56 |
|
|
# <i>cd /usr/portage; ls --classify</i> |
| 57 |
|
|
app-admin/ dev-ml/ gnome-libs/ net-print/ |
| 58 |
|
|
app-arch/ dev-perl/ gnome-office/ net-wireless/ |
| 59 |
|
|
app-benchmarks/ dev-php/ header.txt net-www/ |
| 60 |
|
|
app-cdr/ dev-python/ incoming/ net-zope/ |
| 61 |
|
|
app-crypt/ dev-ruby/ jython/ packages/ |
| 62 |
|
|
app-dicts/ dev-tcltk/ kde-apps/ profiles/ |
| 63 |
|
|
app-doc/ dev-tex/ kde-base/ releases/ |
| 64 |
|
|
app-editors/ dev-util/ kde-i18n/ scripts/ |
| 65 |
|
|
app-emacs/ distfiles/ kde-libs/ sec-policy/ |
| 66 |
|
|
app-emulation/ eclass/ licenses/ skel.ChangeLog |
| 67 |
|
|
app-games/ experimental/ media-fonts/ skel.ebuild |
| 68 |
|
|
app-gnustep/ files/ media-gfx/ skel.metadata.xml |
| 69 |
|
|
app-i18n/ fresco-base/ media-libs/ snapshots/ |
| 70 |
|
|
app-misc/ games-action/ media-plugins/ sys-apps/ |
| 71 |
|
|
app-office/ games-arcade/ media-radio/ sys-build/ |
| 72 |
|
|
app-pda/ games-board/ media-sound/ sys-cluster/ |
| 73 |
|
|
app-portage/ games-emulation/ media-tv/ sys-devel/ |
| 74 |
|
|
app-sci/ games-engines/ media-video/ sys-fs/ |
| 75 |
|
|
app-shells/ games-fps/ metadata/ sys-kernel/ |
| 76 |
|
|
app-text/ games-kids/ net-analyzer/ sys-kmods/ |
| 77 |
|
|
app-vim/ games-misc/ net-apache/ sys-libs/ |
| 78 |
|
|
app-xemacs/ games-mud/ net-dialup/ unix2tcp/ |
| 79 |
|
|
berlin-base/ games-puzzle/ net-dns/ x11-base/ |
| 80 |
|
|
dev-ada/ games-roguelike/ net-firewall/ x11-libs/ |
| 81 |
|
|
dev-cpp/ games-rpg/ net-fs/ x11-misc/ |
| 82 |
|
|
dev-db/ games-server/ net-ftp/ x11-plugins/ |
| 83 |
|
|
dev-dotnet/ games-simulation/ net-im/ x11-terms/ |
| 84 |
|
|
dev-embedded/ games-sports/ net-irc/ x11-themes/ |
| 85 |
|
|
dev-games/ games-strategy/ net-libs/ x11-wm/ |
| 86 |
|
|
dev-haskell/ games-util/ net-mail/ xfce-base/ |
| 87 |
|
|
dev-java/ glep/ net-misc/ xfce-extra/ |
| 88 |
|
|
dev-lang/ gnome-apps/ net-nds/ |
| 89 |
|
|
dev-libs/ gnome-base/ net-news/ |
| 90 |
|
|
dev-lisp/ gnome-extra/ net-p2p/ |
| 91 |
|
|
</pre> |
| 92 |
|
|
|
| 93 |
|
|
<p> |
| 94 |
|
|
As you can see, the Portage tree has several subdirectories. Most of them are |
| 95 |
swift |
1.32 |
the <e>categories</e> in which the Gentoo packages reside. Take a look at, for |
| 96 |
|
|
instance, <path>app-office</path>: |
| 97 |
swift |
1.2 |
</p> |
| 98 |
|
|
|
| 99 |
|
|
<pre caption="Viewing a category"> |
| 100 |
|
|
# <i>cd app-office; ls --classify</i> |
| 101 |
|
|
abiword/ gnotime/ kmymoney2/ ooodi/ plan/ timestamp.x |
| 102 |
|
|
dia/ gnucash/ koffice/ oooqs/ qhacc/ |
| 103 |
|
|
dia2code/ gnumeric/ lxbank/ openoffice/ sc/ |
| 104 |
|
|
facturalux/ ical/ lyx/ openoffice-bin/ scribus/ |
| 105 |
|
|
gaby/ kbudget/ mdbtools/ openoffice-ximian/ siag/ |
| 106 |
|
|
gnofin/ khacc/ mrproject/ phprojekt/ texmacs/ |
| 107 |
|
|
</pre> |
| 108 |
|
|
|
| 109 |
|
|
<p> |
| 110 |
|
|
Inside a category you will find the packages belonging to that category, with a |
| 111 |
swift |
1.12 |
separate directory for each package. Let us take a look at the <c>openoffice</c> |
| 112 |
swift |
1.2 |
package: |
| 113 |
|
|
</p> |
| 114 |
|
|
|
| 115 |
|
|
<pre caption="Viewing a package"> |
| 116 |
|
|
# <i>cd openoffice; ls --classify</i> |
| 117 |
|
|
ChangeLog files/ openoffice-1.0.3-r1.ebuild openoffice-1.1.0-r2.ebuild |
| 118 |
|
|
Manifest metadata.xml openoffice-1.1.0-r1.ebuild openoffice-1.1.0.ebuild |
| 119 |
|
|
</pre> |
| 120 |
|
|
|
| 121 |
|
|
<p> |
| 122 |
swift |
1.32 |
In the example directory, four ebuilds are stored. An <e>ebuild</e> is a script |
| 123 |
|
|
which contains all the necessary information about a specific version of a |
| 124 |
|
|
package. The naming for the ebuilds is almost identical; they only differ in |
| 125 |
|
|
the version name. |
| 126 |
|
|
You are free to view the contents of such an ebuild: they are plain scripts. We |
| 127 |
swift |
1.2 |
will not discuss it right now as it isn't important to know if you plan on just |
| 128 |
|
|
using Gentoo. |
| 129 |
|
|
</p> |
| 130 |
|
|
|
| 131 |
|
|
<p> |
| 132 |
|
|
The other files are the <path>ChangeLog</path> (which contains a listing of all |
| 133 |
|
|
the changes done to the ebuilds), <path>Manifest</path> (which contains the |
| 134 |
swift |
1.20 |
checksums and filesizes of all the files in the directory) and |
| 135 |
swift |
1.2 |
<path>metadata.xml</path> (which contains more information about the package, |
| 136 |
swift |
1.6 |
such as the responsible development group -- called <e>herd</e> -- and a more |
| 137 |
swift |
1.2 |
extensive description). |
| 138 |
|
|
</p> |
| 139 |
|
|
|
| 140 |
|
|
<p> |
| 141 |
swift |
1.28 |
Inside the <path>files</path> directory, you will find extra files, needed by |
| 142 |
swift |
1.32 |
Portage: digests (names, sizes and checksums of the files needed by a single |
| 143 |
swift |
1.2 |
version of the package), patches, example configuration files, etc. |
| 144 |
|
|
</p> |
| 145 |
|
|
|
| 146 |
|
|
<pre caption="Viewing the extra files"> |
| 147 |
|
|
# <i>cd files; ls --classify</i> |
| 148 |
|
|
1.0.3/ digest-openoffice-1.0.3-r1 digest-openoffice-1.1.0-r1 |
| 149 |
|
|
1.1.0/ digest-openoffice-1.1.0 digest-openoffice-1.1.0-r2 |
| 150 |
|
|
# <i>cd 1.1.0; ls --classify</i> |
| 151 |
|
|
fixed-gcc.patch ooffice-wrapper-1.3 |
| 152 |
|
|
newstlportfix.patch openoffice-1.1.0-linux-2.6-fix.patch |
| 153 |
|
|
no-mozab.patch openoffice-1.1.0-sparc64-fix.patch |
| 154 |
|
|
nptl.patch |
| 155 |
|
|
</pre> |
| 156 |
|
|
|
| 157 |
|
|
<p> |
| 158 |
|
|
If you go back to the root of the Portage tree (<path>/usr/portage</path>) you |
| 159 |
swift |
1.28 |
will notice that there are other, non-category directories, too. We will discuss |
| 160 |
swift |
1.2 |
those later in this chapter. |
| 161 |
|
|
</p> |
| 162 |
|
|
|
| 163 |
swift |
1.1 |
</body> |
| 164 |
|
|
</subsection> |
| 165 |
|
|
<subsection> |
| 166 |
|
|
<title>Search for a Package</title> |
| 167 |
|
|
<body> |
| 168 |
|
|
|
| 169 |
swift |
1.2 |
<p> |
| 170 |
|
|
If you are new to Linux or Gentoo, you might not know what tool you need for |
| 171 |
|
|
what job. To facilitate searching, <c>emerge</c> provides you with a way to |
| 172 |
|
|
search through the available packages on your system. There are two ways you can |
| 173 |
|
|
search through packages: by <e>name</e>, or by <e>name</e> and |
| 174 |
|
|
<e>description</e>. |
| 175 |
|
|
</p> |
| 176 |
|
|
|
| 177 |
|
|
<p> |
| 178 |
|
|
To search through the Portage tree by name, use <c>emerge search</c>. For |
| 179 |
|
|
instance, to find out more about <c>mozilla</c>: |
| 180 |
|
|
</p> |
| 181 |
|
|
|
| 182 |
|
|
<pre caption="Showing information about mozilla"> |
| 183 |
|
|
# <i>emerge search mozilla</i> |
| 184 |
|
|
Searching... |
| 185 |
|
|
[ Results for search key : mozilla ] |
| 186 |
|
|
[ Applications found : 5 ] |
| 187 |
|
|
<comment>(Some output removed to improve readability)</comment> |
| 188 |
|
|
* net-www/mozilla |
| 189 |
|
|
Latest version available: 1.5-r1 |
| 190 |
|
|
Latest version installed: 1.4-r3 |
| 191 |
|
|
Size of downloaded files: 29,153 kB |
| 192 |
|
|
Homepage: http://www.mozilla.org |
| 193 |
|
|
Description: The Mozilla Web Browser |
| 194 |
|
|
|
| 195 |
|
|
* net-www/mozilla-firebird |
| 196 |
|
|
Latest version available: 0.7 |
| 197 |
|
|
Latest version installed: [ Not Installed ] |
| 198 |
|
|
Size of downloaded files: 37,850 kB |
| 199 |
|
|
Homepage: http://www.mozilla.org/projects/firebird/ |
| 200 |
|
|
Description: The Mozilla Firebird Web Browser |
| 201 |
|
|
<comment>(...)</comment> |
| 202 |
|
|
</pre> |
| 203 |
|
|
|
| 204 |
|
|
<p> |
| 205 |
|
|
If you want to include a search through the descriptions too, use the |
| 206 |
|
|
<c>--searchdesc</c> argument: |
| 207 |
|
|
</p> |
| 208 |
|
|
|
| 209 |
|
|
<pre caption="Search through the descriptions too"> |
| 210 |
|
|
# <i>emerge --searchdesc mozilla</i> |
| 211 |
|
|
Searching... |
| 212 |
|
|
[ Results for search key : mozilla ] |
| 213 |
|
|
[ Applications found : 10 ] |
| 214 |
|
|
<comment>(Some output removed to improve readability)</comment> |
| 215 |
|
|
* dev-libs/nss-3.8 |
| 216 |
|
|
Latest version available: 3.8 |
| 217 |
|
|
Latest version installed: 3.8 |
| 218 |
|
|
Size of downloaded files: 2,782 kB |
| 219 |
|
|
Homepage: http://www.mozilla.org/projects/security/pki/nss/ |
| 220 |
|
|
Description: Mozilla's Netscape Security Services Library that implements PKI support |
| 221 |
|
|
</pre> |
| 222 |
|
|
|
| 223 |
|
|
<p> |
| 224 |
|
|
As you can see, the output of <c>emerge</c> informs you about the category and |
| 225 |
|
|
name of the package, the available version, the currently installed version, |
| 226 |
|
|
the size of the downloaded files, the homepage and the small description. |
| 227 |
|
|
</p> |
| 228 |
|
|
|
| 229 |
|
|
<p> |
| 230 |
|
|
You see something new? Yes, <e>downloaded files</e>. When you tell Portage to |
| 231 |
swift |
1.4 |
install a package, it of course needs to have the necessary sources (or |
| 232 |
swift |
1.6 |
precompiled packages) available. It therefore checks the contents of |
| 233 |
neysx |
1.33 |
<path>/usr/portage/distfiles</path> to see if the necessary files are already |
| 234 |
|
|
available. If not, it downloads the necessary files and places them in that |
| 235 |
|
|
directory. |
| 236 |
swift |
1.14 |
</p> |
| 237 |
swift |
1.2 |
|
| 238 |
swift |
1.1 |
</body> |
| 239 |
|
|
</subsection> |
| 240 |
swift |
1.3 |
<subsection> |
| 241 |
|
|
<title>Viewing the ChangeLog</title> |
| 242 |
|
|
<body> |
| 243 |
|
|
|
| 244 |
|
|
<p> |
| 245 |
|
|
While browsing through the Portage Tree, you saw that there was a ChangeLog for |
| 246 |
swift |
1.17 |
each package. You can view the ChangeLog entries between the available version |
| 247 |
|
|
and the installed version with <c>emerge</c> too. Use the |
| 248 |
swift |
1.3 |
<c>--pretend --changelog</c> (<c>-pl</c> in short) options. As an example we |
| 249 |
|
|
will view the ChangeLog entries for <c>gnumeric</c>: |
| 250 |
|
|
</p> |
| 251 |
|
|
|
| 252 |
|
|
<pre caption="Viewing the ChangeLog entries for gnumeric"> |
| 253 |
|
|
# <i>emerge --pretend --changelog gnumeric</i> |
| 254 |
swift |
1.17 |
<comment>(Some output removed to improve readability)</comment> |
| 255 |
|
|
*gnumeric-1.2.2 |
| 256 |
|
|
|
| 257 |
|
|
27 Nov 2003; foser <foser@gentoo.org> gnumeric-1.2.2.ebuild : |
| 258 |
|
|
New release, requested in #34492 |
| 259 |
|
|
updated deps |
| 260 |
|
|
|
| 261 |
|
|
12 Nov 2003; Jason Wever <weeve@gentoo.org> gnumeric-1.2.0.ebuild: |
| 262 |
|
|
Marked stable on sparc, fixes bug #32405. |
| 263 |
|
|
|
| 264 |
|
|
14 Oct 2003; Jason Wever <weeve@gentoo.org> gnumeric-1.0.8.ebuild: |
| 265 |
|
|
Added ~sparc keyword. Fixes bug #31150. |
| 266 |
swift |
1.3 |
</pre> |
| 267 |
|
|
|
| 268 |
|
|
</body> |
| 269 |
|
|
</subsection> |
| 270 |
swift |
1.1 |
</section> |
| 271 |
|
|
<section> |
| 272 |
|
|
<title>Updating Portage</title> |
| 273 |
|
|
<subsection> |
| 274 |
swift |
1.2 |
<title>Introduction</title> |
| 275 |
|
|
<body> |
| 276 |
|
|
|
| 277 |
|
|
<p> |
| 278 |
|
|
Searching through Portage is nice, but if you don't update your Portage Tree |
| 279 |
|
|
regularly, you will be stuck with the packages and versions available on your |
| 280 |
swift |
1.6 |
system. This means that your system will get outdated pretty soon and that |
| 281 |
|
|
you will be missing bugfixes and remedies for possible security problems. |
| 282 |
swift |
1.2 |
</p> |
| 283 |
|
|
|
| 284 |
|
|
<p> |
| 285 |
|
|
There are several ways to update your Portage Tree. The most popular method is |
| 286 |
|
|
by using one of our <uri link="/main/en/mirrors.xml">rsync mirrors</uri>. |
| 287 |
|
|
Another one is by using a Portage snapshot (in case a firewall or unavailability |
| 288 |
|
|
of a network prohibits the use of the rsync server). |
| 289 |
|
|
</p> |
| 290 |
|
|
|
| 291 |
|
|
</body> |
| 292 |
|
|
</subsection> |
| 293 |
|
|
<subsection> |
| 294 |
|
|
<title>Selecting a Mirror for rsync</title> |
| 295 |
swift |
1.1 |
<body> |
| 296 |
|
|
|
| 297 |
swift |
1.2 |
<p> |
| 298 |
|
|
It is adviseable to first select a fast <uri |
| 299 |
|
|
link="/main/en/mirrors.xml">mirror</uri> close to you. You can do this manually |
| 300 |
|
|
(by setting the <c>SYNC</c> variable in <path>/etc/make.conf</path>) or use |
| 301 |
|
|
<c>mirrorselect</c> to do this for you automatically. As the <c>SYNC</c> |
| 302 |
|
|
variable will be discussed later on, we will focus on using <c>mirrorselect</c>. |
| 303 |
|
|
First install <c>mirrorselect</c> by emerging it: |
| 304 |
|
|
</p> |
| 305 |
|
|
|
| 306 |
|
|
<pre caption="Installing mirrorselect"> |
| 307 |
|
|
# <i>emerge --usepkg mirrorselect</i> |
| 308 |
|
|
</pre> |
| 309 |
|
|
|
| 310 |
|
|
<p> |
| 311 |
|
|
Now run <c>mirrorselect</c> to automatically select mirrors for you (it will |
| 312 |
swift |
1.15 |
also setup Portage to use a mirror for the source code): |
| 313 |
swift |
1.2 |
</p> |
| 314 |
|
|
|
| 315 |
|
|
<pre caption="Running mirrorselect"> |
| 316 |
|
|
# <i>mirrorselect -a -s3</i> |
| 317 |
|
|
</pre> |
| 318 |
|
|
|
| 319 |
swift |
1.1 |
</body> |
| 320 |
|
|
</subsection> |
| 321 |
|
|
<subsection> |
| 322 |
swift |
1.2 |
<title>Updating Portage</title> |
| 323 |
swift |
1.1 |
<body> |
| 324 |
swift |
1.2 |
|
| 325 |
|
|
<p> |
| 326 |
|
|
To update Portage using rsync, simply run <c>emerge sync</c>: |
| 327 |
|
|
</p> |
| 328 |
|
|
|
| 329 |
|
|
<pre caption="Updating Portage using emerge sync"> |
| 330 |
|
|
# <i>emerge sync</i> |
| 331 |
|
|
</pre> |
| 332 |
|
|
|
| 333 |
|
|
<p> |
| 334 |
|
|
If this fails (due to network problems, or a firewall), you can try using |
| 335 |
|
|
<c>emerge-webrsync</c> which will download a Portage Tree snapshot using |
| 336 |
|
|
<c>wget</c>. This also means that you can use proxies if you want. We discussed |
| 337 |
|
|
how to setup your system to use proxies during the Gentoo installation. |
| 338 |
|
|
</p> |
| 339 |
|
|
|
| 340 |
|
|
<pre caption="Updating Portage using emerge-webrsync"> |
| 341 |
|
|
# <i>emerge-webrsync</i> |
| 342 |
|
|
</pre> |
| 343 |
swift |
1.1 |
|
| 344 |
|
|
</body> |
| 345 |
|
|
</subsection> |
| 346 |
|
|
</section> |
| 347 |
|
|
<section> |
| 348 |
|
|
<title>Maintaining Software</title> |
| 349 |
|
|
<subsection> |
| 350 |
swift |
1.8 |
<title>Building or Prebuilt?</title> |
| 351 |
swift |
1.1 |
<body> |
| 352 |
|
|
|
| 353 |
swift |
1.3 |
<p> |
| 354 |
|
|
Gentoo provides ebuilds, the Gentoo packages if you like. But when you want to |
| 355 |
swift |
1.15 |
install such an ebuild, you can choose between <e>building</e> the package and |
| 356 |
swift |
1.8 |
using a <e>prebuilt</e> package. But what are the advantages/disadvantages of |
| 357 |
swift |
1.3 |
both approaches, and can they be used next to each other? |
| 358 |
|
|
</p> |
| 359 |
|
|
|
| 360 |
|
|
<p> |
| 361 |
|
|
As you probably have guessed, building packages takes a lot of time (especially |
| 362 |
|
|
if you have little resources or want to build big packages, such as <uri |
| 363 |
|
|
link="http://www.kde.org">KDE</uri>, <uri |
| 364 |
|
|
link="http://www.openoffice.org">OpenOffice.org</uri>, etc.). By building the |
| 365 |
|
|
package, you can use the <c>USE</c> setting to tweak the package to your system. |
| 366 |
swift |
1.4 |
Of course, you can also define high optimization options (in the <c>CFLAGS</c> |
| 367 |
swift |
1.3 |
and <c>CXXFLAGS</c> variables) to compile the package with. |
| 368 |
|
|
</p> |
| 369 |
|
|
|
| 370 |
|
|
<p> |
| 371 |
swift |
1.8 |
Using prebuilt packages improves the installation time (as no more compilation |
| 372 |
swift |
1.3 |
is needed), but you will lose the advantages of the <c>USE</c> setting and the |
| 373 |
|
|
<c>CFLAGS</c> & <c>CXXFLAGS</c> variables. |
| 374 |
|
|
</p> |
| 375 |
|
|
|
| 376 |
|
|
<p> |
| 377 |
swift |
1.8 |
As previously stated, prebuilt packages are stored in the |
| 378 |
swift |
1.15 |
<path>/usr/portage/packages/All</path> directory, while the source code of the |
| 379 |
|
|
packages is placed in <path>/usr/portage/distfiles</path>. If you have finished |
| 380 |
|
|
installing a package you can remove the package or source code from the |
| 381 |
|
|
respective directory. However, you might want to keep the package/source code of |
| 382 |
swift |
1.3 |
the latest version, just in case you want to reinstall the package (so you don't |
| 383 |
|
|
have to redownload it). |
| 384 |
|
|
</p> |
| 385 |
|
|
|
| 386 |
|
|
</body> |
| 387 |
|
|
</subsection> |
| 388 |
|
|
<subsection> |
| 389 |
|
|
<title>Installing Software from Sources</title> |
| 390 |
|
|
<body> |
| 391 |
|
|
|
| 392 |
|
|
<p> |
| 393 |
|
|
Okay, enough talking, let's cut to the chase. To install a package, you will use |
| 394 |
swift |
1.8 |
the <c>emerge</c> command. If you don't want to use any prebuilt packages, you |
| 395 |
swift |
1.3 |
can just use <c>emerge <package-name></c> or <c>emerge |
| 396 |
|
|
<category>/<package-name></c>. As an example we'll install |
| 397 |
|
|
<c>gnumeric</c>: |
| 398 |
|
|
</p> |
| 399 |
|
|
|
| 400 |
|
|
<pre caption="Building gnumeric"> |
| 401 |
|
|
# <i>emerge gnumeric</i> |
| 402 |
|
|
</pre> |
| 403 |
|
|
|
| 404 |
|
|
<p> |
| 405 |
swift |
1.15 |
This will download the source code for you and unpacks, compiles and installs |
| 406 |
|
|
the package on your system. It will also do the same for all the dependencies. |
| 407 |
|
|
If you want to see what dependencies will be installed with it, use the |
| 408 |
swift |
1.3 |
<c>--pretend</c> option (<c>-p</c> in short): |
| 409 |
|
|
</p> |
| 410 |
|
|
|
| 411 |
|
|
<pre caption="Pretending to build gnumeric"> |
| 412 |
|
|
# <i>emerge --pretend gnumeric</i> |
| 413 |
|
|
</pre> |
| 414 |
|
|
|
| 415 |
|
|
<p> |
| 416 |
swift |
1.15 |
If you want to download the source code of the package and its dependencies, |
| 417 |
swift |
1.3 |
but don't want to build the package, use the <c>--fetchonly</c> option |
| 418 |
|
|
(<c>-f</c> in short): |
| 419 |
|
|
</p> |
| 420 |
|
|
|
| 421 |
|
|
<pre caption="Fetching sources for gnumeric"> |
| 422 |
|
|
# <i>emerge --fetchonly gnumeric</i> |
| 423 |
|
|
</pre> |
| 424 |
|
|
|
| 425 |
|
|
<p> |
| 426 |
|
|
If you want to see where <c>emerge</c> downloads the sources from, combine the |
| 427 |
|
|
<c>--fetchonly</c> and <c>--pretend</c> options: |
| 428 |
|
|
</p> |
| 429 |
|
|
|
| 430 |
|
|
<pre caption="Showing URLs of the sources for gnumeric"> |
| 431 |
|
|
# <i>emerge --fetchonly --pretend gnumeric</i> |
| 432 |
|
|
</pre> |
| 433 |
|
|
|
| 434 |
|
|
<p> |
| 435 |
|
|
You can also opt to install a specific version of a package. |
| 436 |
|
|
For instance, if you want to install a gnumeric version older than 1.2 -- for |
| 437 |
|
|
any reason whatsoever :) you would type: |
| 438 |
|
|
</p> |
| 439 |
|
|
|
| 440 |
|
|
<pre caption="Installing a specific gnumeric version"> |
| 441 |
|
|
# <i>emerge "<gnumeric-1.2"</i> |
| 442 |
|
|
</pre> |
| 443 |
|
|
|
| 444 |
|
|
<p> |
| 445 |
swift |
1.4 |
Other possibilities are of course ">" (later version) and "=" (the exact |
| 446 |
swift |
1.3 |
version). |
| 447 |
|
|
</p> |
| 448 |
|
|
|
| 449 |
|
|
</body> |
| 450 |
|
|
</subsection> |
| 451 |
|
|
<subsection> |
| 452 |
swift |
1.8 |
<title>Installing Prebuilt Packages</title> |
| 453 |
swift |
1.3 |
<body> |
| 454 |
|
|
|
| 455 |
|
|
<p> |
| 456 |
swift |
1.8 |
When you want to install a prebuilt package, you should use the <c>--usepkg</c> |
| 457 |
swift |
1.3 |
option (<c>-k</c> in short). This will use the binary package available in |
| 458 |
|
|
<path>/usr/portage/packages/All</path> <e>if</e> the package and the version of |
| 459 |
|
|
the application you want to install match. |
| 460 |
|
|
</p> |
| 461 |
|
|
|
| 462 |
swift |
1.8 |
<pre caption="Installing a prebuilt package for gnumeric"> |
| 463 |
swift |
1.3 |
# <i>emerge --usepkg gnumeric</i> |
| 464 |
|
|
</pre> |
| 465 |
|
|
|
| 466 |
|
|
<p> |
| 467 |
|
|
If you want to use the binary package, even if the versions don't match, use |
| 468 |
|
|
<c>--usepkgonly</c> (<c>-K</c> in short). |
| 469 |
|
|
</p> |
| 470 |
|
|
|
| 471 |
swift |
1.8 |
<pre caption="Installing the prebuilt package for gnumeric"> |
| 472 |
swift |
1.3 |
# <i>emerge --usepkgonly gnumeric</i> |
| 473 |
|
|
</pre> |
| 474 |
|
|
|
| 475 |
|
|
<p> |
| 476 |
swift |
1.8 |
If you don't have the prebuilt package on your system yet, you can have |
| 477 |
swift |
1.3 |
<c>emerge</c> download it from a mirror, defined in the <c>PORTAGE_BINHOST</c> |
| 478 |
|
|
variable declared in <path>/etc/make.conf</path>. |
| 479 |
|
|
</p> |
| 480 |
|
|
|
| 481 |
swift |
1.32 |
<note> |
| 482 |
|
|
Gentoo does not have any server or mirror containing such prebuilt packages. |
| 483 |
|
|
Portage has been extended with this feature to fullfil the community request. |
| 484 |
|
|
</note> |
| 485 |
|
|
|
| 486 |
swift |
1.3 |
<p> |
| 487 |
|
|
To download the binary package in case this package doesn't exist on |
| 488 |
swift |
1.10 |
your system already, use <c>--getbinpkg</c> (<c>-g</c> in short): |
| 489 |
swift |
1.3 |
</p> |
| 490 |
|
|
|
| 491 |
swift |
1.8 |
<pre caption="Downloading and installing a prebuilt package for gnumeric"> |
| 492 |
swift |
1.10 |
# <i>emerge --getbinpkg gnumeric</i> |
| 493 |
swift |
1.3 |
</pre> |
| 494 |
|
|
|
| 495 |
|
|
<p> |
| 496 |
|
|
This will download the package and the package-related information for you and |
| 497 |
|
|
install it on your system, together with the dependencies. If you want to see |
| 498 |
swift |
1.10 |
what dependencies will be installed with it, use the <c>--pretend</c> option |
| 499 |
swift |
1.3 |
(<c>-p</c> in short): |
| 500 |
|
|
</p> |
| 501 |
|
|
|
| 502 |
swift |
1.8 |
<pre caption="Pretending to download the prebuilt packages for gnumeric"> |
| 503 |
swift |
1.10 |
# <i>emerge --getbinpkg --pretend gnumeric</i> |
| 504 |
swift |
1.3 |
</pre> |
| 505 |
|
|
|
| 506 |
|
|
<p> |
| 507 |
swift |
1.8 |
You can also opt to download the prebuilt package (and the package-related |
| 508 |
swift |
1.3 |
information) <e>without</e> checking the information on your local system and |
| 509 |
swift |
1.8 |
<e>without</e> using the prebuilt package already on your system (if |
| 510 |
swift |
1.10 |
applicable), use the <c>--getbinpkgonly</c> option (<c>-G</c> in short): |
| 511 |
swift |
1.3 |
</p> |
| 512 |
|
|
|
| 513 |
swift |
1.8 |
<pre caption="Installing a prebuilt package without using local information"> |
| 514 |
swift |
1.10 |
# <i>emerge --getbinpkgonly gnumeric</i> |
| 515 |
swift |
1.3 |
</pre> |
| 516 |
|
|
|
| 517 |
|
|
<p> |
| 518 |
|
|
You can also opt to install a specific version of a package. |
| 519 |
|
|
For instance, if you want to install a gnumeric version older than 1.2 -- for |
| 520 |
|
|
any reason whatsoever :) you would type: |
| 521 |
|
|
</p> |
| 522 |
|
|
|
| 523 |
|
|
<pre caption="Installing a specific gnumeric version"> |
| 524 |
|
|
# <i>emerge --usepkg "<gnumeric-1.2"</i> |
| 525 |
|
|
</pre> |
| 526 |
|
|
|
| 527 |
|
|
<p> |
| 528 |
swift |
1.4 |
Other possibilities are of course ">" (later version) and "=" (the exact |
| 529 |
swift |
1.3 |
version). |
| 530 |
|
|
</p> |
| 531 |
|
|
|
| 532 |
|
|
|
| 533 |
swift |
1.1 |
</body> |
| 534 |
|
|
</subsection> |
| 535 |
|
|
<subsection> |
| 536 |
swift |
1.11 |
<title>Working with Dependencies</title> |
| 537 |
|
|
<body> |
| 538 |
|
|
|
| 539 |
|
|
<p> |
| 540 |
|
|
Portage has an extensive support for dependency handling. Although you usually |
| 541 |
|
|
don't need to even think about this (as dependencies are automatically handled |
| 542 |
|
|
by Portage) some users might want to know how you can work with <c>emerge</c> |
| 543 |
|
|
and dependencies. |
| 544 |
|
|
</p> |
| 545 |
|
|
|
| 546 |
|
|
<p> |
| 547 |
|
|
For instance, if you want Portage to pretend that none of the dependencies of a |
| 548 |
|
|
package are installed, you can use <c>--emptytree</c> (<c>-e</c> in short). This |
| 549 |
|
|
is useful with <c>--pretend</c> to display a complete tree of dependencies for |
| 550 |
|
|
any particular package. Without <c>--pretend</c>, <c>emerge</c> will (re)compile |
| 551 |
swift |
1.24 |
all listed packages. |
| 552 |
swift |
1.11 |
</p> |
| 553 |
|
|
|
| 554 |
|
|
<pre caption="Show all dependencies of gnumeric"> |
| 555 |
|
|
# <i>emerge --emptytree --pretend gnumeric</i> |
| 556 |
|
|
</pre> |
| 557 |
|
|
|
| 558 |
|
|
<p> |
| 559 |
|
|
Another argument is <c>--nodeps</c>, which will ask Portage to try install the |
| 560 |
|
|
given package without taking care of the dependencies. It is trivial that this |
| 561 |
|
|
can lead to failures. |
| 562 |
|
|
</p> |
| 563 |
|
|
|
| 564 |
|
|
<pre caption="Installing gnumeric without taking care of the dependencies"> |
| 565 |
|
|
# <i>emerge --nodeps gnumeric</i> |
| 566 |
|
|
</pre> |
| 567 |
|
|
|
| 568 |
|
|
<p> |
| 569 |
swift |
1.15 |
The opposite of <c>--nodeps</c> is <c>--onlydeps</c>, which will have Portage |
| 570 |
swift |
1.11 |
install all dependencies of a given package, but not the package itself: |
| 571 |
|
|
</p> |
| 572 |
|
|
|
| 573 |
|
|
<pre caption="Installing the dependencies of gnumeric"> |
| 574 |
|
|
# <i>emerge --onlydeps gnumeric</i> |
| 575 |
|
|
</pre> |
| 576 |
|
|
|
| 577 |
|
|
</body> |
| 578 |
|
|
</subsection> |
| 579 |
|
|
<subsection> |
| 580 |
swift |
1.3 |
<title>Updating your System</title> |
| 581 |
swift |
1.1 |
<body> |
| 582 |
|
|
|
| 583 |
swift |
1.3 |
<p> |
| 584 |
|
|
Portage knows two special tags to denote a set of software packages: |
| 585 |
|
|
<e>system</e> and <e>world</e>. You have already seen the former while |
| 586 |
|
|
installing Gentoo if you didn't use a <e>stage3</e> installation. To refresh |
| 587 |
|
|
things: <e>system</e> is the collection of <e>core</e> packages, necessary to |
| 588 |
|
|
have a working Gentoo system. |
| 589 |
|
|
</p> |
| 590 |
|
|
|
| 591 |
|
|
<p> |
| 592 |
|
|
The <e>world</e> tag consists of all software you have installed yourself on |
| 593 |
|
|
your system plus the <e>system</e> information. In other words, every time you |
| 594 |
|
|
emerge a package using <c>emerge <package-name></c>, the |
| 595 |
|
|
<c><package-name></c> is registered in the <e>world</e> file |
| 596 |
|
|
(<path>/var/cache/edb/world</path>). Dependencies are <e>not</e> part of the |
| 597 |
|
|
<e>world</e> file, but we will get to that later. |
| 598 |
|
|
</p> |
| 599 |
|
|
|
| 600 |
|
|
<p> |
| 601 |
|
|
If you want to update the system packages, use the <c>--update</c> option |
| 602 |
|
|
(<c>-u</c> in short): |
| 603 |
|
|
</p> |
| 604 |
|
|
|
| 605 |
|
|
<pre caption="Updating the system packages"> |
| 606 |
|
|
# <i>emerge --update system</i> |
| 607 |
|
|
</pre> |
| 608 |
|
|
|
| 609 |
|
|
<p> |
| 610 |
|
|
An identical approach can be used for the world packages: |
| 611 |
|
|
</p> |
| 612 |
|
|
|
| 613 |
|
|
<pre caption="Updating your entire system"> |
| 614 |
|
|
# <i>emerge --update world</i> |
| 615 |
|
|
</pre> |
| 616 |
|
|
|
| 617 |
|
|
<p> |
| 618 |
|
|
Again, if you want to see what <c>emerge</c> wants to update, use the |
| 619 |
|
|
<c>--pretend</c> option together with the <c>--update</c> option: |
| 620 |
|
|
</p> |
| 621 |
|
|
|
| 622 |
|
|
<pre caption="Pretending to update your entire system"> |
| 623 |
|
|
# <i>emerge --pretend --update world</i> |
| 624 |
|
|
<comment>(Some output removed to improve readability)</comment> |
| 625 |
|
|
[ebuild U ] net-misc/wget-1.9-r1 [1.9] |
| 626 |
|
|
[ebuild UD] media-video/dvdauthor-0.5.0 [0.5.3] |
| 627 |
|
|
[ebuild U ] net-analyzer/ethereal-0.9.16 [0.9.14] |
| 628 |
|
|
</pre> |
| 629 |
|
|
|
| 630 |
|
|
<p> |
| 631 |
|
|
Right next to the word "ebuild" you will notice a letter (or combination of |
| 632 |
|
|
letters) which gives you more information about the package: |
| 633 |
|
|
</p> |
| 634 |
|
|
|
| 635 |
|
|
<ul> |
| 636 |
|
|
<li> |
| 637 |
|
|
<e>B</e> (blocks) The package listed to the left is blocking the emerge of |
| 638 |
|
|
the package listed to the right |
| 639 |
|
|
</li> |
| 640 |
|
|
<li> |
| 641 |
|
|
<e>N</e> (new) The package is new to your system and will be emerged for the |
| 642 |
|
|
first time |
| 643 |
|
|
</li> |
| 644 |
|
|
<li> |
| 645 |
swift |
1.32 |
<e>R</e> (replace) The package isn't new, but will be reemerged |
| 646 |
swift |
1.3 |
</li> |
| 647 |
|
|
<li> |
| 648 |
swift |
1.15 |
<e>F</e> (fetch) The package requires that you download the source code |
| 649 |
swift |
1.3 |
manually (for instance due to licencing issues) |
| 650 |
|
|
</li> |
| 651 |
|
|
<li> |
| 652 |
|
|
<e>U</e> (update) The package already exists on your system but will be |
| 653 |
|
|
upgraded |
| 654 |
|
|
</li> |
| 655 |
|
|
<li> |
| 656 |
|
|
<e>UD</e> (downgrade) The package already exists on your system but will be |
| 657 |
|
|
downgraded |
| 658 |
|
|
</li> |
| 659 |
|
|
</ul> |
| 660 |
|
|
|
| 661 |
|
|
<p> |
| 662 |
swift |
1.25 |
We have mentioned that the <e>world</e> file doesn't contain dependencies. When |
| 663 |
|
|
you run <c>emerge --update world</c> only the packages mentioned in the |
| 664 |
|
|
<e>world</e> file and it's immediate dependencies are checked and, if necessary, |
| 665 |
|
|
upgraded. If you want <c>emerge</c> to check <e>all</e> the dependencies |
| 666 |
|
|
(including the dependencies of the dependencies), add the <c>--deep</c> flag: |
| 667 |
|
|
</p> |
| 668 |
|
|
|
| 669 |
|
|
<pre caption="Upgrading your entire system, including all dependencies"> |
| 670 |
|
|
# <i>emerge --update --deep world</i> |
| 671 |
|
|
</pre> |
| 672 |
|
|
|
| 673 |
|
|
<p> |
| 674 |
swift |
1.4 |
Of course, we are talking here about <e>system</e> and <e>world</e>, but you can |
| 675 |
swift |
1.3 |
perform the same actions for individual software packages. |
| 676 |
|
|
</p> |
| 677 |
|
|
|
| 678 |
swift |
1.1 |
</body> |
| 679 |
|
|
</subsection> |
| 680 |
|
|
<subsection> |
| 681 |
|
|
<title>Removing Software</title> |
| 682 |
|
|
<body> |
| 683 |
|
|
|
| 684 |
swift |
1.3 |
<p> |
| 685 |
|
|
If you want to remove software from your system, you can use the <c>unmerge</c> |
| 686 |
|
|
option (<c>-C</c> - capital C - in short): |
| 687 |
|
|
</p> |
| 688 |
|
|
|
| 689 |
|
|
<pre caption="Uninstalling software"> |
| 690 |
|
|
# <i>emerge unmerge gnumeric</i> |
| 691 |
|
|
</pre> |
| 692 |
|
|
|
| 693 |
|
|
<p> |
| 694 |
|
|
If you want to test a removal (but not perform it), you can use <c>--pretend</c> |
| 695 |
|
|
again: |
| 696 |
|
|
</p> |
| 697 |
|
|
|
| 698 |
|
|
<pre caption="Pretending to uninstall software"> |
| 699 |
|
|
# <i>emerge --pretend unmerge gnumeric</i> |
| 700 |
|
|
</pre> |
| 701 |
|
|
|
| 702 |
|
|
<warn> |
| 703 |
|
|
Portage doesn't verify if a package is a dependency for another |
| 704 |
|
|
installed package. It also doesn't warn you if the package is part of |
| 705 |
|
|
<e>system</e>, i.e. a core application necessary for the correct functioning of |
| 706 |
|
|
your system! |
| 707 |
|
|
</warn> |
| 708 |
swift |
1.11 |
|
| 709 |
|
|
<p> |
| 710 |
|
|
Once the unmerge begins you will see a long list of filenames belonging to the |
| 711 |
|
|
package. Some of these filenames will have a flag displayed to the |
| 712 |
|
|
left of the filename. The flags <c>!mtime</c>, <c>!empty</c>, and <c>cfgpro</c> |
| 713 |
|
|
specify reasons why certain files are not being removed while the package is. |
| 714 |
|
|
Files listed without any of these three flags are removed from the |
| 715 |
|
|
filesystem successfully. The three flags specify the following reasons: |
| 716 |
|
|
</p> |
| 717 |
|
|
|
| 718 |
|
|
<ul> |
| 719 |
|
|
<li> |
| 720 |
|
|
<c>!mtime</c> : The listed file has been changed since it was installed, |
| 721 |
|
|
probably by you or some tool |
| 722 |
|
|
</li> |
| 723 |
|
|
<li> |
| 724 |
|
|
<c>!empty</c> : The listed directory is not empty |
| 725 |
|
|
</li> |
| 726 |
|
|
<li> |
| 727 |
swift |
1.16 |
<c>cfgpro</c> : This file is located inside a protected directory and will |
| 728 |
|
|
not be touched for safety |
| 729 |
swift |
1.11 |
</li> |
| 730 |
|
|
</ul> |
| 731 |
swift |
1.3 |
|
| 732 |
swift |
1.1 |
</body> |
| 733 |
|
|
</subsection> |
| 734 |
|
|
</section> |
| 735 |
|
|
<section> |
| 736 |
swift |
1.30 |
<title>Working with Masked Packages</title> |
| 737 |
swift |
1.1 |
<subsection> |
| 738 |
|
|
<title>ARCH or not?</title> |
| 739 |
|
|
<body> |
| 740 |
|
|
|
| 741 |
swift |
1.3 |
<p> |
| 742 |
|
|
Gentoo places its packages in two possible stadia called <e>ARCH</e> and |
| 743 |
|
|
<e>~ARCH</e>. Don't take this literally: the stadia depend on the architecture |
| 744 |
|
|
you are using. In other words, for x86-based systems you have <e>x86</e> and |
| 745 |
|
|
<e>~x86</e>, for ppc-based systems you have <e>ppc</e> and <e>~ppc</e> etc. |
| 746 |
|
|
</p> |
| 747 |
|
|
|
| 748 |
|
|
<p> |
| 749 |
|
|
The <e>~ARCH</e> stadium means that the package works for the developer in |
| 750 |
|
|
charge of the package, but that the package hasn't been tested thoroughly enough |
| 751 |
|
|
by the community to be placed in <e>ARCH</e>. <e>~ARCH</e> packages usually go |
| 752 |
|
|
to <e>ARCH</e> after being bugfree for a sufficient amount of time. |
| 753 |
|
|
</p> |
| 754 |
|
|
|
| 755 |
|
|
<p> |
| 756 |
|
|
Your system will use <e>ARCH</e> packages per default. If you want to live on |
| 757 |
swift |
1.21 |
the edge, don't mind having a broken package once in a while, know how to deal |
| 758 |
|
|
with a broken system and you like submitting bugreports to <uri |
| 759 |
swift |
1.3 |
link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, then you can opt to use |
| 760 |
|
|
<e>~ARCH</e> packages. To "move" your system to a <e>~ARCH</e>-using system, |
| 761 |
|
|
edit the <c>ACCEPT_KEYWORDS</c> variable in <path>/etc/make.conf</path> so that |
| 762 |
|
|
it reads <e>~ARCH</e> (again: for x86-based systems: <e>~x86</e>, etc.). |
| 763 |
|
|
</p> |
| 764 |
|
|
|
| 765 |
|
|
<p> |
| 766 |
swift |
1.21 |
Note though that it is far from trivial (if even impossible) to go back to |
| 767 |
|
|
<e>ARCH</e> from <e>~ARCH</e>. |
| 768 |
|
|
</p> |
| 769 |
|
|
|
| 770 |
|
|
<p> |
| 771 |
swift |
1.3 |
If you want to update your system now, you will notice that <e>a lot</e> of |
| 772 |
|
|
packages will be updated! |
| 773 |
|
|
</p> |
| 774 |
|
|
|
| 775 |
swift |
1.1 |
</body> |
| 776 |
|
|
</subsection> |
| 777 |
|
|
<subsection> |
| 778 |
|
|
<title>Masked Packages</title> |
| 779 |
|
|
<body> |
| 780 |
|
|
|
| 781 |
swift |
1.3 |
<p> |
| 782 |
|
|
When you want to install a package, you might come across the following message: |
| 783 |
|
|
</p> |
| 784 |
|
|
|
| 785 |
|
|
<pre caption="Message about masked packages"> |
| 786 |
|
|
Calculating dependencies |
| 787 |
|
|
!!! <comment>all ebuilds that could satisfy </comment><your package><comment> have been masked.</comment> |
| 788 |
|
|
</pre> |
| 789 |
|
|
|
| 790 |
|
|
<p> |
| 791 |
swift |
1.32 |
A package can be masked due to several reasons: |
| 792 |
swift |
1.3 |
</p> |
| 793 |
|
|
|
| 794 |
|
|
<ol> |
| 795 |
|
|
<li>The package is in <e>~ARCH</e> while you use <e>ARCH</e></li> |
| 796 |
|
|
<li>The package is hard-masked explicitly</li> |
| 797 |
swift |
1.32 |
<li>The package isn't available for your ARCH entirely</li> |
| 798 |
|
|
<li>The package is masked by your profile</li> |
| 799 |
swift |
1.3 |
</ol> |
| 800 |
|
|
|
| 801 |
|
|
<p> |
| 802 |
neysx |
1.27 |
If the package is masked because of the first reason, and you <e>really</e> |
| 803 |
|
|
want to install it (knowing that there <e>is</e> a reason why it isn't |
| 804 |
|
|
available in <e>ARCH</e>), you can accept the <e>~ARCH</e> version of any |
| 805 |
|
|
package by adding it to your <path>/etc/portage/package.keywords</path> file: |
| 806 |
swift |
1.3 |
</p> |
| 807 |
|
|
|
| 808 |
neysx |
1.27 |
<pre caption="Accepting the ~ARCH version of a package"> |
| 809 |
swift |
1.29 |
<comment>(Create the /etc/portage directory if it doesn't exist yet)</comment> |
| 810 |
|
|
# <i>mkdir /etc/portage</i> |
| 811 |
|
|
|
| 812 |
neysx |
1.27 |
# <i>echo "app-office/gnumeric ~x86" >> /etc/portage/package.keywords</i> |
| 813 |
|
|
# <i>emerge gnumeric</i> |
| 814 |
swift |
1.3 |
</pre> |
| 815 |
|
|
|
| 816 |
|
|
<p> |
| 817 |
|
|
A package is hardmasked if it is listed in |
| 818 |
|
|
<path>/usr/portage/profiles/package.mask</path>. If you read this file, you |
| 819 |
|
|
will also read the reason why the package is hardmasked (it is usually added as |
| 820 |
|
|
a comment). If you want to install the package nevertheless (despite all the |
| 821 |
|
|
possible warnings we could ever throw at your head about "breaking your system", |
| 822 |
|
|
"breaks other packages", or "badly needs testing"), create the |
| 823 |
|
|
<path>/etc/portage/package.unmask</path> file and list the package in it (use |
| 824 |
|
|
the same format as is used in <path>/usr/portage/profiles/package.mask</path>). |
| 825 |
|
|
</p> |
| 826 |
|
|
|
| 827 |
swift |
1.29 |
<pre caption="Unmasking a hard-masked application"> |
| 828 |
|
|
<comment>(Create the /etc/portage directory if it doesn't exist yet)</comment> |
| 829 |
|
|
# <i>mkdir /etc/portage</i> |
| 830 |
|
|
|
| 831 |
|
|
# <i>echo "=app-office/gnumeric-1.2.12" >> /etc/portage/package.unmask</i> |
| 832 |
|
|
</pre> |
| 833 |
|
|
|
| 834 |
swift |
1.3 |
<p> |
| 835 |
|
|
Do <e>not</e> alter the <path>/usr/portage/profiles/package.mask</path> file as |
| 836 |
swift |
1.29 |
all changes are undone the next time you update your Portage tree. |
| 837 |
|
|
</p> |
| 838 |
|
|
|
| 839 |
|
|
<p> |
| 840 |
|
|
Sometimes you might want to hardmask a (collection of) package(s). This is the |
| 841 |
|
|
case when newer versions of an application don't support something you require |
| 842 |
|
|
or when these versions break something else in your environment. |
| 843 |
swift |
1.3 |
</p> |
| 844 |
|
|
|
| 845 |
|
|
<p> |
| 846 |
swift |
1.29 |
To hard-mask a package, create <path>/etc/portage/package.mask</path> and list the |
| 847 |
|
|
package in it (use the same format as mentioned above). |
| 848 |
swift |
1.3 |
</p> |
| 849 |
|
|
|
| 850 |
swift |
1.29 |
<pre caption="Hard-masking a package"> |
| 851 |
|
|
<comment>(Create the /etc/portage directory if it doesn't exist yet)</comment> |
| 852 |
|
|
# <i>mkdir /etc/portage</i> |
| 853 |
|
|
|
| 854 |
|
|
# <i>echo ">app-office/gnumeric-1.2.10" >> /etc/portage/package.mask</i> |
| 855 |
swift |
1.3 |
</pre> |
| 856 |
|
|
|
| 857 |
swift |
1.1 |
</body> |
| 858 |
|
|
</subsection> |
| 859 |
|
|
<subsection> |
| 860 |
|
|
<title>Blocked Packages</title> |
| 861 |
|
|
<body> |
| 862 |
swift |
1.3 |
|
| 863 |
|
|
<p> |
| 864 |
|
|
You have a situation when you receive the following error on your screen: |
| 865 |
|
|
</p> |
| 866 |
|
|
|
| 867 |
|
|
<pre caption="Blocking package"> |
| 868 |
|
|
[blocks B ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0) |
| 869 |
|
|
</pre> |
| 870 |
|
|
|
| 871 |
|
|
<p> |
| 872 |
|
|
In the above example, the package <c>bonobo-activation</c> is blocking the |
| 873 |
|
|
emerge of <c>libbonobo</c>. To resolve this issue, remove the |
| 874 |
|
|
<c>bonobo-activation</c> package and continue: |
| 875 |
|
|
</p> |
| 876 |
|
|
|
| 877 |
|
|
<pre caption="Resolving a blocking situation"> |
| 878 |
|
|
# <i>emerge unmerge bonobo-activation</i> |
| 879 |
|
|
</pre> |
| 880 |
swift |
1.1 |
|
| 881 |
|
|
</body> |
| 882 |
|
|
</subsection> |
| 883 |
|
|
</section> |
| 884 |
|
|
</sections> |