| 1 | <?xml version='1.0' encoding='UTF-8'?> |
1 | <?xml version='1.0' encoding='UTF-8'?> |
| 2 | <!DOCTYPE sections SYSTEM "/dtd/book.dtd"> |
2 | <!DOCTYPE sections SYSTEM "/dtd/book.dtd"> |
| 3 | |
3 | |
| 4 | <!-- The content of this document is licensed under the CC-BY-SA license --> |
4 | <!-- The content of this document is licensed under the CC-BY-SA license --> |
| 5 | <!-- See http://creativecommons.org/licenses/by-sa/1.0 --> |
5 | <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 6 | |
6 | |
| 7 | <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.19 2004/01/09 10:52:18 dertobi123 Exp $ --> |
7 | <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.78 2011/10/26 19:46:19 swift Exp $ --> |
| 8 | |
8 | |
| 9 | <sections> |
9 | <sections> |
|
|
10 | |
|
|
11 | <abstract> |
|
|
12 | This chapter explains the "simple" steps a user definitely needs to know to |
|
|
13 | maintain the software on his system. |
|
|
14 | </abstract> |
|
|
15 | |
|
|
16 | <version>4</version> |
|
|
17 | <date>2011-10-26</date> |
|
|
18 | |
| 10 | <section> |
19 | <section> |
| 11 | <title>Obtaining Package Information</title> |
20 | <title>Welcome to Portage</title> |
| 12 | <subsection> |
|
|
| 13 | <title>The Lord of All Tools: emerge</title> |
|
|
| 14 | <body> |
21 | <body> |
| 15 | |
22 | |
| 16 | <p> |
|
|
| 17 | 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 | and teach you how to use <c>emerge</c> to fix all your software-related needs. |
|
|
| 21 | </p> |
23 | <p> |
| 22 | |
24 | Portage is probably Gentoo's most notable innovation in software management. |
|
|
25 | With its high flexibility and enormous amount of features it is frequently seen |
|
|
26 | as the best software management tool available for Linux. |
| 23 | <p> |
27 | </p> |
| 24 | <c>emerge</c> is the command used to install, remove, query and maintain |
28 | |
| 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> |
29 | <p> |
| 30 | |
30 | Portage is completely written in <uri link="http://www.python.org">Python</uri> |
|
|
31 | and <uri link="http://www.gnu.org/software/bash">Bash</uri> and therefore fully |
|
|
32 | visible to the users as both are scripting languages. |
| 31 | <p> |
33 | </p> |
| 32 | Since <c>emerge</c> is the most important tool for Gentoo users, it has an |
34 | |
| 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> |
35 | <p> |
|
|
36 | Most users will work with Portage through the <c>emerge</c> tool. This chapter |
|
|
37 | is not meant to duplicate the information available from the emerge man page. |
|
|
38 | For a complete rundown of emerge's options, please consult the man page: |
|
|
39 | </p> |
| 36 | |
40 | |
| 37 | <pre caption="Retrieving help for emerge"> |
41 | <pre caption="Reading the emerge man page"> |
| 38 | # <i>man emerge</i> |
42 | $ <i>man emerge</i> |
| 39 | # <i>emerge --help</i> |
|
|
| 40 | </pre> |
43 | </pre> |
| 41 | |
44 | |
| 42 | </body> |
|
|
| 43 | </subsection> |
|
|
| 44 | <subsection> |
|
|
| 45 | <title>The Portage Tree</title> |
|
|
| 46 | <body> |
45 | </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 | directories. We use <c>ls --classify</c> to list the contents of a |
|
|
| 52 | directory as it will show directories with a trailing "/". |
|
|
| 53 | </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 | the <e>categories</e> in which the Gentoo packages, called <e>ebuilds</e>, |
|
|
| 96 | reside. Take a look at, for instance, <path>app-office</path>: |
|
|
| 97 | </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 | separate directory for each package. Let us take a look at the <c>openoffice</c> |
|
|
| 112 | 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 | Remember that we told you that a Gentoo package is called an ebuild? Well, in |
|
|
| 123 | the example directory four of such ebuilds are stored. Their naming is |
|
|
| 124 | almost identical: they only differ in the version name. |
|
|
| 125 | You are free to view the contents of such a package: they are plain scripts. We |
|
|
| 126 | will not discuss it right now as it isn't important to know if you plan on just |
|
|
| 127 | using Gentoo. |
|
|
| 128 | </p> |
|
|
| 129 | |
|
|
| 130 | <p> |
|
|
| 131 | The other files are the <path>ChangeLog</path> (which contains a listing of all |
|
|
| 132 | the changes done to the ebuilds), <path>Manifest</path> (which contains the |
|
|
| 133 | checksums and permissions of all the files in the directory) and |
|
|
| 134 | <path>metadata.xml</path> (which contains more information about the package, |
|
|
| 135 | such as the responsible development group -- called <e>herd</e> -- and a more |
|
|
| 136 | extensive description). |
|
|
| 137 | </p> |
|
|
| 138 | |
|
|
| 139 | <p> |
|
|
| 140 | Inside the <path>files</path> directory you will find extra files, needed by |
|
|
| 141 | Portage: digests (checksums and permissions of the files needed by a single |
|
|
| 142 | version of the package), patches, example configuration files, etc. |
|
|
| 143 | </p> |
|
|
| 144 | |
|
|
| 145 | <pre caption="Viewing the extra files"> |
|
|
| 146 | # <i>cd files; ls --classify</i> |
|
|
| 147 | 1.0.3/ digest-openoffice-1.0.3-r1 digest-openoffice-1.1.0-r1 |
|
|
| 148 | 1.1.0/ digest-openoffice-1.1.0 digest-openoffice-1.1.0-r2 |
|
|
| 149 | # <i>cd 1.1.0; ls --classify</i> |
|
|
| 150 | fixed-gcc.patch ooffice-wrapper-1.3 |
|
|
| 151 | newstlportfix.patch openoffice-1.1.0-linux-2.6-fix.patch |
|
|
| 152 | no-mozab.patch openoffice-1.1.0-sparc64-fix.patch |
|
|
| 153 | nptl.patch |
|
|
| 154 | </pre> |
|
|
| 155 | |
|
|
| 156 | <p> |
|
|
| 157 | If you go back to the root of the Portage tree (<path>/usr/portage</path>) you |
|
|
| 158 | will notice that there are other, non-category directories too. We will discuss |
|
|
| 159 | those later in this chapter. |
|
|
| 160 | </p> |
|
|
| 161 | |
|
|
| 162 | </body> |
|
|
| 163 | </subsection> |
|
|
| 164 | <subsection> |
|
|
| 165 | <title>Search for a Package</title> |
|
|
| 166 | <body> |
|
|
| 167 | |
|
|
| 168 | <p> |
|
|
| 169 | If you are new to Linux or Gentoo, you might not know what tool you need for |
|
|
| 170 | what job. To facilitate searching, <c>emerge</c> provides you with a way to |
|
|
| 171 | search through the available packages on your system. There are two ways you can |
|
|
| 172 | search through packages: by <e>name</e>, or by <e>name</e> and |
|
|
| 173 | <e>description</e>. |
|
|
| 174 | </p> |
|
|
| 175 | |
|
|
| 176 | <p> |
|
|
| 177 | To search through the Portage tree by name, use <c>emerge search</c>. For |
|
|
| 178 | instance, to find out more about <c>mozilla</c>: |
|
|
| 179 | </p> |
|
|
| 180 | |
|
|
| 181 | <pre caption="Showing information about mozilla"> |
|
|
| 182 | # <i>emerge search mozilla</i> |
|
|
| 183 | Searching... |
|
|
| 184 | [ Results for search key : mozilla ] |
|
|
| 185 | [ Applications found : 5 ] |
|
|
| 186 | <comment>(Some output removed to improve readability)</comment> |
|
|
| 187 | * net-www/mozilla |
|
|
| 188 | Latest version available: 1.5-r1 |
|
|
| 189 | Latest version installed: 1.4-r3 |
|
|
| 190 | Size of downloaded files: 29,153 kB |
|
|
| 191 | Homepage: http://www.mozilla.org |
|
|
| 192 | Description: The Mozilla Web Browser |
|
|
| 193 | |
|
|
| 194 | * net-www/mozilla-firebird |
|
|
| 195 | Latest version available: 0.7 |
|
|
| 196 | Latest version installed: [ Not Installed ] |
|
|
| 197 | Size of downloaded files: 37,850 kB |
|
|
| 198 | Homepage: http://www.mozilla.org/projects/firebird/ |
|
|
| 199 | Description: The Mozilla Firebird Web Browser |
|
|
| 200 | <comment>(...)</comment> |
|
|
| 201 | </pre> |
|
|
| 202 | |
|
|
| 203 | <p> |
|
|
| 204 | If you want to include a search through the descriptions too, use the |
|
|
| 205 | <c>--searchdesc</c> argument: |
|
|
| 206 | </p> |
|
|
| 207 | |
|
|
| 208 | <pre caption="Search through the descriptions too"> |
|
|
| 209 | # <i>emerge --searchdesc mozilla</i> |
|
|
| 210 | Searching... |
|
|
| 211 | [ Results for search key : mozilla ] |
|
|
| 212 | [ Applications found : 10 ] |
|
|
| 213 | <comment>(Some output removed to improve readability)</comment> |
|
|
| 214 | * dev-libs/nss-3.8 |
|
|
| 215 | Latest version available: 3.8 |
|
|
| 216 | Latest version installed: 3.8 |
|
|
| 217 | Size of downloaded files: 2,782 kB |
|
|
| 218 | Homepage: http://www.mozilla.org/projects/security/pki/nss/ |
|
|
| 219 | Description: Mozilla's Netscape Security Services Library that implements PKI support |
|
|
| 220 | </pre> |
|
|
| 221 | |
|
|
| 222 | <p> |
|
|
| 223 | As you can see, the output of <c>emerge</c> informs you about the category and |
|
|
| 224 | name of the package, the available version, the currently installed version, |
|
|
| 225 | the size of the downloaded files, the homepage and the small description. |
|
|
| 226 | </p> |
|
|
| 227 | |
|
|
| 228 | <p> |
|
|
| 229 | You see something new? Yes, <e>downloaded files</e>. When you tell Portage to |
|
|
| 230 | install a package, it of course needs to have the necessary sources (or |
|
|
| 231 | precompiled packages) available. It therefore checks the contents of |
|
|
| 232 | <path>/usr/portage/distfiles</path> (for source code) or |
|
|
| 233 | <path>/usr/portage/packages/All</path> (for precompiled packages) to see if the |
|
|
| 234 | necessary files are already available. If not, it downloads the necessary files |
|
|
| 235 | and places them in those directories. |
|
|
| 236 | </p> |
|
|
| 237 | |
|
|
| 238 | <!-- |
|
|
| 239 | <note> |
|
|
| 240 | Searching the Portage Tree, especially when using <c>- -searchdesc</c>, is very |
|
|
| 241 | time consuming. There are other, more performant tools available. We will |
|
|
| 242 | describe those in the chapter on <uri link="?part=2&chap=7">Gentoolkit and |
|
|
| 243 | Other Tools</uri>. |
|
|
| 244 | </note> |
|
|
| 245 | --> |
|
|
| 246 | |
|
|
| 247 | </body> |
|
|
| 248 | </subsection> |
|
|
| 249 | <subsection> |
|
|
| 250 | <title>Viewing the ChangeLog</title> |
|
|
| 251 | <body> |
|
|
| 252 | |
|
|
| 253 | <p> |
|
|
| 254 | While browsing through the Portage Tree, you saw that there was a ChangeLog for |
|
|
| 255 | each package. You can view the ChangeLog entries between the available version |
|
|
| 256 | and the installed version with <c>emerge</c> too. Use the |
|
|
| 257 | <c>--pretend --changelog</c> (<c>-pl</c> in short) options. As an example we |
|
|
| 258 | will view the ChangeLog entries for <c>gnumeric</c>: |
|
|
| 259 | </p> |
|
|
| 260 | |
|
|
| 261 | <pre caption="Viewing the ChangeLog entries for gnumeric"> |
|
|
| 262 | # <i>emerge --pretend --changelog gnumeric</i> |
|
|
| 263 | <comment>(Some output removed to improve readability)</comment> |
|
|
| 264 | *gnumeric-1.2.2 |
|
|
| 265 | |
|
|
| 266 | 27 Nov 2003; foser <foser@gentoo.org> gnumeric-1.2.2.ebuild : |
|
|
| 267 | New release, requested in #34492 |
|
|
| 268 | updated deps |
|
|
| 269 | |
|
|
| 270 | 12 Nov 2003; Jason Wever <weeve@gentoo.org> gnumeric-1.2.0.ebuild: |
|
|
| 271 | Marked stable on sparc, fixes bug #32405. |
|
|
| 272 | |
|
|
| 273 | 14 Oct 2003; Jason Wever <weeve@gentoo.org> gnumeric-1.0.8.ebuild: |
|
|
| 274 | Added ~sparc keyword. Fixes bug #31150. |
|
|
| 275 | </pre> |
|
|
| 276 | |
|
|
| 277 | </body> |
|
|
| 278 | </subsection> |
|
|
| 279 | </section> |
46 | </section> |
| 280 | <section> |
47 | <section> |
| 281 | <title>Updating Portage</title> |
48 | <title>The Portage Tree</title> |
| 282 | <subsection> |
|
|
| 283 | <title>Introduction</title> |
|
|
| 284 | <body> |
|
|
| 285 | |
|
|
| 286 | <p> |
|
|
| 287 | Searching through Portage is nice, but if you don't update your Portage Tree |
|
|
| 288 | regularly, you will be stuck with the packages and versions available on your |
|
|
| 289 | system. This means that your system will get outdated pretty soon and that |
|
|
| 290 | you will be missing bugfixes and remedies for possible security problems. |
|
|
| 291 | </p> |
|
|
| 292 | |
|
|
| 293 | <p> |
|
|
| 294 | There are several ways to update your Portage Tree. The most popular method is |
|
|
| 295 | by using one of our <uri link="/main/en/mirrors.xml">rsync mirrors</uri>. |
|
|
| 296 | Another one is by using a Portage snapshot (in case a firewall or unavailability |
|
|
| 297 | of a network prohibits the use of the rsync server). |
|
|
| 298 | </p> |
|
|
| 299 | |
|
|
| 300 | </body> |
|
|
| 301 | </subsection> |
49 | <subsection> |
|
|
50 | <title>Ebuilds</title> |
|
|
51 | <body> |
|
|
52 | |
|
|
53 | <p> |
|
|
54 | When we talk about packages, we often mean software titles that are available to |
|
|
55 | the Gentoo users through the Portage tree. The Portage tree is a collection of |
|
|
56 | <e>ebuilds</e>, files that contain all information Portage needs to maintain |
|
|
57 | software (install, search, query, ...). These ebuilds reside in |
|
|
58 | <path>/usr/portage</path> by default. |
|
|
59 | </p> |
|
|
60 | |
|
|
61 | <p> |
|
|
62 | Whenever you ask Portage to perform some action regarding software titles, it |
|
|
63 | will use the ebuilds on your system as a base. It is therefore important that |
|
|
64 | you regularly update the ebuilds on your system so Portage knows about new |
|
|
65 | software, security updates, etc. |
|
|
66 | </p> |
|
|
67 | |
|
|
68 | </body> |
| 302 | <subsection> |
69 | </subsection> |
| 303 | <title>Selecting a Mirror for rsync</title> |
|
|
| 304 | <body> |
|
|
| 305 | |
|
|
| 306 | <p> |
|
|
| 307 | It is adviseable to first select a fast <uri |
|
|
| 308 | link="/main/en/mirrors.xml">mirror</uri> close to you. You can do this manually |
|
|
| 309 | (by setting the <c>SYNC</c> variable in <path>/etc/make.conf</path>) or use |
|
|
| 310 | <c>mirrorselect</c> to do this for you automatically. As the <c>SYNC</c> |
|
|
| 311 | variable will be discussed later on, we will focus on using <c>mirrorselect</c>. |
|
|
| 312 | First install <c>mirrorselect</c> by emerging it: |
|
|
| 313 | </p> |
|
|
| 314 | |
|
|
| 315 | <pre caption="Installing mirrorselect"> |
|
|
| 316 | # <i>emerge --usepkg mirrorselect</i> |
|
|
| 317 | </pre> |
|
|
| 318 | |
|
|
| 319 | <p> |
|
|
| 320 | Now run <c>mirrorselect</c> to automatically select mirrors for you (it will |
|
|
| 321 | also setup Portage to use a mirror for the source code): |
|
|
| 322 | </p> |
|
|
| 323 | |
|
|
| 324 | <pre caption="Running mirrorselect"> |
|
|
| 325 | # <i>mirrorselect -a -s3</i> |
|
|
| 326 | </pre> |
|
|
| 327 | |
|
|
| 328 | </body> |
|
|
| 329 | </subsection> |
70 | <subsection> |
| 330 | <subsection> |
|
|
| 331 | <title>Updating Portage</title> |
71 | <title>Updating the Portage Tree</title> |
| 332 | <body> |
72 | <body> |
| 333 | |
73 | |
| 334 | <p> |
|
|
| 335 | To update Portage using rsync, simply run <c>emerge sync</c>: |
|
|
| 336 | </p> |
74 | <p> |
|
|
75 | The Portage tree is usually updated with <uri |
|
|
76 | link="http://rsync.samba.org/">rsync</uri>, a fast incremental file transfer |
|
|
77 | utility. Updating is fairly simple as the <c>emerge</c> command provides a |
|
|
78 | front-end for rsync: |
|
|
79 | </p> |
| 337 | |
80 | |
| 338 | <pre caption="Updating Portage using emerge sync"> |
81 | <pre caption="Updating the Portage tree"> |
| 339 | # <i>emerge sync</i> |
82 | # <i>emerge --sync</i> |
| 340 | </pre> |
83 | </pre> |
| 341 | |
84 | |
| 342 | <p> |
|
|
| 343 | If this fails (due to network problems, or a firewall), you can try using |
|
|
| 344 | <c>emerge-webrsync</c> which will download a Portage Tree snapshot using |
|
|
| 345 | <c>wget</c>. This also means that you can use proxies if you want. We discussed |
|
|
| 346 | how to setup your system to use proxies during the Gentoo installation. |
|
|
| 347 | </p> |
85 | <p> |
|
|
86 | If you are unable to rsync due to firewall restrictions you can still update |
|
|
87 | your Portage tree by using our daily generated Portage tree snapshots. The |
|
|
88 | <c>emerge-webrsync</c> tool automatically fetches and installs the latest |
|
|
89 | snapshot on your system: |
|
|
90 | </p> |
| 348 | |
91 | |
| 349 | <pre caption="Updating Portage using emerge-webrsync"> |
92 | <pre caption="Running emerge-webrsync"> |
| 350 | # <i>emerge-webrsync</i> |
93 | # <i>emerge-webrsync</i> |
| 351 | </pre> |
94 | </pre> |
|
|
95 | |
|
|
96 | <p> |
|
|
97 | An additional advantage of using <c>emerge-webrsync</c> is that it allows the |
|
|
98 | administrator to only pull in portage tree snapshots that are signed by the |
|
|
99 | Gentoo release engineering GPG key. More information on this can be found |
|
|
100 | in the <uri link="?part=2&chap=3">Portage Features</uri> section on |
|
|
101 | <uri link="?part=2&chap=3#webrsync-gpg">Fetching Validated Portage Tree |
|
|
102 | Snapshots</uri>. |
|
|
103 | </p> |
| 352 | |
104 | |
| 353 | </body> |
105 | </body> |
| 354 | </subsection> |
106 | </subsection> |
| 355 | </section> |
107 | </section> |
| 356 | <section> |
108 | <section> |
| 357 | <title>Maintaining Software</title> |
109 | <title>Maintaining Software</title> |
| 358 | <subsection> |
110 | <subsection> |
| 359 | <title>Building or Prebuilt?</title> |
111 | <title>Searching for Software</title> |
| 360 | <body> |
|
|
| 361 | |
|
|
| 362 | <p> |
|
|
| 363 | Gentoo provides ebuilds, the Gentoo packages if you like. But when you want to |
|
|
| 364 | install such an ebuild, you can choose between <e>building</e> the package and |
|
|
| 365 | using a <e>prebuilt</e> package. But what are the advantages/disadvantages of |
|
|
| 366 | both approaches, and can they be used next to each other? |
|
|
| 367 | </p> |
|
|
| 368 | |
|
|
| 369 | <p> |
|
|
| 370 | As you probably have guessed, building packages takes a lot of time (especially |
|
|
| 371 | if you have little resources or want to build big packages, such as <uri |
|
|
| 372 | link="http://www.kde.org">KDE</uri>, <uri |
|
|
| 373 | link="http://www.openoffice.org">OpenOffice.org</uri>, etc.). By building the |
|
|
| 374 | package, you can use the <c>USE</c> setting to tweak the package to your system. |
|
|
| 375 | Of course, you can also define high optimization options (in the <c>CFLAGS</c> |
|
|
| 376 | and <c>CXXFLAGS</c> variables) to compile the package with. |
|
|
| 377 | </p> |
|
|
| 378 | |
|
|
| 379 | <p> |
|
|
| 380 | Using prebuilt packages improves the installation time (as no more compilation |
|
|
| 381 | is needed), but you will lose the advantages of the <c>USE</c> setting and the |
|
|
| 382 | <c>CFLAGS</c> & <c>CXXFLAGS</c> variables. |
|
|
| 383 | </p> |
|
|
| 384 | |
|
|
| 385 | <p> |
|
|
| 386 | As previously stated, prebuilt packages are stored in the |
|
|
| 387 | <path>/usr/portage/packages/All</path> directory, while the source code of the |
|
|
| 388 | packages is placed in <path>/usr/portage/distfiles</path>. If you have finished |
|
|
| 389 | installing a package you can remove the package or source code from the |
|
|
| 390 | respective directory. However, you might want to keep the package/source code of |
|
|
| 391 | the latest version, just in case you want to reinstall the package (so you don't |
|
|
| 392 | have to redownload it). |
|
|
| 393 | </p> |
|
|
| 394 | |
|
|
| 395 | </body> |
112 | <body> |
| 396 | </subsection> |
113 | |
|
|
114 | <p> |
|
|
115 | To search through the Portage tree after software titles, you can use |
|
|
116 | <c>emerge</c> built-in search capabilities. By default, <c>emerge --search</c> |
|
|
117 | returns the names of packages whose title matches (either fully or partially) |
|
|
118 | the given search term. |
|
|
119 | </p> |
|
|
120 | |
|
|
121 | <p> |
|
|
122 | For instance, to search for all packages who have "pdf" in their name: |
|
|
123 | </p> |
|
|
124 | |
|
|
125 | <pre caption="Searching for pdf-named packages"> |
|
|
126 | $ <i>emerge --search pdf</i> |
|
|
127 | </pre> |
|
|
128 | |
|
|
129 | <p> |
|
|
130 | If you want to search through the descriptions as well you can use the |
|
|
131 | <c>--searchdesc</c> (or <c>-S</c>) switch: |
|
|
132 | </p> |
|
|
133 | |
|
|
134 | <pre caption="Searching for pdf-related packages"> |
|
|
135 | $ <i>emerge --searchdesc pdf</i> |
|
|
136 | </pre> |
|
|
137 | |
|
|
138 | <p> |
|
|
139 | When you take a look at the output, you'll notice that it gives you a lot of |
|
|
140 | information. The fields are clearly labelled so we won't go further into their |
|
|
141 | meanings: |
|
|
142 | </p> |
|
|
143 | |
|
|
144 | <pre caption="Example 'emerge --search' output"> |
|
|
145 | * net-print/cups-pdf |
|
|
146 | Latest version available: 1.5.2 |
|
|
147 | Latest version installed: [ Not Installed ] |
|
|
148 | Size of downloaded files: 15 kB |
|
|
149 | Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/ |
|
|
150 | Description: Provides a virtual printer for CUPS to produce PDF files. |
|
|
151 | License: GPL-2 |
|
|
152 | </pre> |
|
|
153 | |
|
|
154 | </body> |
| 397 | <subsection> |
155 | </subsection> |
|
|
156 | <subsection> |
| 398 | <title>Installing Software from Sources</title> |
157 | <title>Installing Software</title> |
| 399 | <body> |
158 | <body> |
| 400 | |
159 | |
| 401 | <p> |
160 | <p> |
| 402 | Okay, enough talking, let's cut to the chase. To install a package, you will use |
161 | Once you've found a software title to your liking, you can easily install it |
| 403 | the <c>emerge</c> command. If you don't want to use any prebuilt packages, you |
162 | with <c>emerge</c>: just add the package name. For instance, to install |
| 404 | can just use <c>emerge <package-name></c> or <c>emerge |
|
|
| 405 | <category>/<package-name></c>. As an example we'll install |
|
|
| 406 | <c>gnumeric</c>: |
163 | <c>gnumeric</c>: |
| 407 | </p> |
164 | </p> |
| 408 | |
165 | |
| 409 | <pre caption="Building gnumeric"> |
166 | <pre caption="Installing gnumeric"> |
| 410 | # <i>emerge gnumeric</i> |
167 | # <i>emerge gnumeric</i> |
| 411 | </pre> |
168 | </pre> |
| 412 | |
169 | |
| 413 | <p> |
170 | <p> |
| 414 | This will download the source code for you and unpacks, compiles and installs |
171 | Since many applications depend on each other, any attempt to install a certain |
| 415 | the package on your system. It will also do the same for all the dependencies. |
172 | software package might result in the installation of several dependencies as |
| 416 | If you want to see what dependencies will be installed with it, use the |
173 | well. Don't worry, Portage handles dependencies well. If you want to find out |
| 417 | <c>--pretend</c> option (<c>-p</c> in short): |
174 | what Portage <e>would</e> install when you ask it to install a certain package, |
|
|
175 | add the <c>--pretend</c> switch. For instance: |
| 418 | </p> |
176 | </p> |
| 419 | |
177 | |
| 420 | <pre caption="Pretending to build gnumeric"> |
178 | <pre caption="Pretend to install gnumeric"> |
| 421 | # <i>emerge --pretend gnumeric</i> |
179 | # <i>emerge --pretend gnumeric</i> |
| 422 | </pre> |
180 | </pre> |
| 423 | |
181 | |
| 424 | <p> |
182 | <p> |
| 425 | If you want to download the source code of the package and its dependencies, |
183 | When you ask Portage to install a package, it will download the necessary source |
| 426 | but don't want to build the package, use the <c>--fetchonly</c> option |
184 | code from the internet (if necessary) and store it by default in |
| 427 | (<c>-f</c> in short): |
185 | <path>/usr/portage/distfiles</path>. After this it will unpack, compile and |
|
|
186 | install the package. If you want Portage to only download the sources without |
|
|
187 | installing them, add the <c>--fetchonly</c> option to the <c>emerge</c> command: |
| 428 | </p> |
188 | </p> |
| 429 | |
189 | |
| 430 | <pre caption="Fetching sources for gnumeric"> |
190 | <pre caption="Download the sourcecode for gnumeric"> |
| 431 | # <i>emerge --fetchonly gnumeric</i> |
191 | # <i>emerge --fetchonly gnumeric</i> |
| 432 | </pre> |
192 | </pre> |
| 433 | |
193 | |
| 434 | <p> |
|
|
| 435 | If you want to see where <c>emerge</c> downloads the sources from, combine the |
|
|
| 436 | <c>--fetchonly</c> and <c>--pretend</c> options: |
|
|
| 437 | </p> |
|
|
| 438 | |
|
|
| 439 | <pre caption="Showing URLs of the sources for gnumeric"> |
|
|
| 440 | # <i>emerge --fetchonly --pretend gnumeric</i> |
|
|
| 441 | </pre> |
|
|
| 442 | |
|
|
| 443 | <p> |
|
|
| 444 | You can also opt to install a specific version of a package. |
|
|
| 445 | For instance, if you want to install a gnumeric version older than 1.2 -- for |
|
|
| 446 | any reason whatsoever :) you would type: |
|
|
| 447 | </p> |
|
|
| 448 | |
|
|
| 449 | <pre caption="Installing a specific gnumeric version"> |
|
|
| 450 | # <i>emerge "<gnumeric-1.2"</i> |
|
|
| 451 | </pre> |
|
|
| 452 | |
|
|
| 453 | <p> |
|
|
| 454 | Other possibilities are of course ">" (later version) and "=" (the exact |
|
|
| 455 | version). |
|
|
| 456 | </p> |
|
|
| 457 | |
|
|
| 458 | </body> |
194 | </body> |
| 459 | </subsection> |
|
|
| 460 | <subsection> |
195 | </subsection> |
| 461 | <title>Installing Prebuilt Packages</title> |
|
|
| 462 | <body> |
|
|
| 463 | |
|
|
| 464 | <p> |
|
|
| 465 | When you want to install a prebuilt package, you should use the <c>--usepkg</c> |
|
|
| 466 | option (<c>-k</c> in short). This will use the binary package available in |
|
|
| 467 | <path>/usr/portage/packages/All</path> <e>if</e> the package and the version of |
|
|
| 468 | the application you want to install match. |
|
|
| 469 | </p> |
|
|
| 470 | |
|
|
| 471 | <pre caption="Installing a prebuilt package for gnumeric"> |
|
|
| 472 | # <i>emerge --usepkg gnumeric</i> |
|
|
| 473 | </pre> |
|
|
| 474 | |
|
|
| 475 | <p> |
|
|
| 476 | If you want to use the binary package, even if the versions don't match, use |
|
|
| 477 | <c>--usepkgonly</c> (<c>-K</c> in short). |
|
|
| 478 | </p> |
|
|
| 479 | |
|
|
| 480 | <pre caption="Installing the prebuilt package for gnumeric"> |
|
|
| 481 | # <i>emerge --usepkgonly gnumeric</i> |
|
|
| 482 | </pre> |
|
|
| 483 | |
|
|
| 484 | <p> |
|
|
| 485 | If you don't have the prebuilt package on your system yet, you can have |
|
|
| 486 | <c>emerge</c> download it from a mirror, defined in the <c>PORTAGE_BINHOST</c> |
|
|
| 487 | variable declared in <path>/etc/make.conf</path>. |
|
|
| 488 | </p> |
|
|
| 489 | |
|
|
| 490 | <p> |
|
|
| 491 | To download the binary package in case this package doesn't exist on |
|
|
| 492 | your system already, use <c>--getbinpkg</c> (<c>-g</c> in short): |
|
|
| 493 | </p> |
|
|
| 494 | |
|
|
| 495 | <pre caption="Downloading and installing a prebuilt package for gnumeric"> |
|
|
| 496 | # <i>emerge --getbinpkg gnumeric</i> |
|
|
| 497 | </pre> |
|
|
| 498 | |
|
|
| 499 | <p> |
|
|
| 500 | This will download the package and the package-related information for you and |
|
|
| 501 | install it on your system, together with the dependencies. If you want to see |
|
|
| 502 | what dependencies will be installed with it, use the <c>--pretend</c> option |
|
|
| 503 | (<c>-p</c> in short): |
|
|
| 504 | </p> |
|
|
| 505 | |
|
|
| 506 | <pre caption="Pretending to download the prebuilt packages for gnumeric"> |
|
|
| 507 | # <i>emerge --getbinpkg --pretend gnumeric</i> |
|
|
| 508 | </pre> |
|
|
| 509 | |
|
|
| 510 | <p> |
|
|
| 511 | You can also opt to download the prebuilt package (and the package-related |
|
|
| 512 | information) <e>without</e> checking the information on your local system and |
|
|
| 513 | <e>without</e> using the prebuilt package already on your system (if |
|
|
| 514 | applicable), use the <c>--getbinpkgonly</c> option (<c>-G</c> in short): |
|
|
| 515 | </p> |
|
|
| 516 | |
|
|
| 517 | <pre caption="Installing a prebuilt package without using local information"> |
|
|
| 518 | # <i>emerge --getbinpkgonly gnumeric</i> |
|
|
| 519 | </pre> |
|
|
| 520 | |
|
|
| 521 | <p> |
|
|
| 522 | You can also opt to install a specific version of a package. |
|
|
| 523 | For instance, if you want to install a gnumeric version older than 1.2 -- for |
|
|
| 524 | any reason whatsoever :) you would type: |
|
|
| 525 | </p> |
|
|
| 526 | |
|
|
| 527 | <pre caption="Installing a specific gnumeric version"> |
|
|
| 528 | # <i>emerge --usepkg "<gnumeric-1.2"</i> |
|
|
| 529 | </pre> |
|
|
| 530 | |
|
|
| 531 | <p> |
|
|
| 532 | Other possibilities are of course ">" (later version) and "=" (the exact |
|
|
| 533 | version). |
|
|
| 534 | </p> |
|
|
| 535 | |
|
|
| 536 | |
|
|
| 537 | </body> |
|
|
| 538 | </subsection> |
196 | <subsection> |
|
|
197 | <title>Finding Installed Package Documentation</title> |
|
|
198 | <body> |
|
|
199 | |
|
|
200 | <p> |
|
|
201 | Many packages come with their own documentation. Sometimes, the <c>doc</c> USE |
|
|
202 | flag determines whether the package documentation should be installed or not. |
|
|
203 | You can check the existence of a <c>doc</c> USE flag with the <c>emerge -vp |
|
|
204 | <package name></c> command. |
|
|
205 | </p> |
|
|
206 | |
|
|
207 | <pre caption="Checking the existence of a doc USE flag"> |
|
|
208 | <comment>(alsa-lib is just an example, of course.)</comment> |
|
|
209 | # <i>emerge -vp alsa-lib</i> |
|
|
210 | [ebuild N ] media-libs/alsa-lib-1.0.14_rc1 -debug +doc 698 kB |
|
|
211 | </pre> |
|
|
212 | |
|
|
213 | <p> |
|
|
214 | The best way of enabling the <c>doc</c> USE flag is doing it on a per-package |
|
|
215 | basis via <path>/etc/portage/package.use</path>, so that you get documentation |
|
|
216 | only for packages that you are interested in. Enabling this flag globally is |
|
|
217 | known to cause problems with circular dependencies. For more information, please |
|
|
218 | read the <uri link="?part=2&chap=2">USE Flags</uri> chapter. |
|
|
219 | </p> |
|
|
220 | |
|
|
221 | <p> |
|
|
222 | Once the package installed, its documentation is generally found in a |
|
|
223 | subdirectory named after the package under the <path>/usr/share/doc</path> |
|
|
224 | directory. You can also list all installed files with the <c>equery</c> tool |
|
|
225 | which is part of the <c>app-portage/gentoolkit</c> <uri |
|
|
226 | link="/doc/en/gentoolkit.xml">package</uri>. |
|
|
227 | </p> |
|
|
228 | |
|
|
229 | <pre caption="Locating package documentation"> |
|
|
230 | # <i>ls -l /usr/share/doc/alsa-lib-1.0.14_rc1</i> |
|
|
231 | total 28 |
|
|
232 | -rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz |
|
|
233 | -rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz |
|
|
234 | drwxr-xr-x 2 root root 8560 May 17 21:54 html |
|
|
235 | -rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz |
|
|
236 | |
|
|
237 | <comment>(Alternatively, use equery to locate interesting files:)</comment> |
|
|
238 | # <i>equery files alsa-lib | less</i> |
|
|
239 | media-libs/alsa-lib-1.0.14_rc1 |
|
|
240 | * Contents of media-libs/alsa-lib-1.0.14_rc1: |
|
|
241 | /usr |
|
|
242 | /usr/bin |
|
|
243 | /usr/bin/alsalisp |
|
|
244 | <comment>(Output truncated)</comment> |
|
|
245 | </pre> |
|
|
246 | |
|
|
247 | </body> |
| 539 | <subsection> |
248 | </subsection> |
| 540 | <title>Working with Dependencies</title> |
249 | <subsection> |
|
|
250 | <title>Removing Software</title> |
| 541 | <body> |
251 | <body> |
| 542 | |
252 | |
| 543 | <p> |
|
|
| 544 | Portage has an extensive support for dependency handling. Although you usually |
|
|
| 545 | don't need to even think about this (as dependencies are automatically handled |
|
|
| 546 | by Portage) some users might want to know how you can work with <c>emerge</c> |
|
|
| 547 | and dependencies. |
|
|
| 548 | </p> |
253 | <p> |
| 549 | |
254 | When you want to remove a software package from your system, use <c>emerge |
|
|
255 | --unmerge</c>. This will tell Portage to remove all files installed by that |
|
|
256 | package from your system <e>except</e> the configuration files of that |
|
|
257 | application if you have altered those after the installation. Leaving the |
|
|
258 | configuration files allows you to continue working with the package if you ever |
|
|
259 | decide to install it again. |
| 550 | <p> |
260 | </p> |
| 551 | For instance, if you want Portage to pretend that none of the dependencies of a |
261 | |
| 552 | package are installed, you can use <c>--emptytree</c> (<c>-e</c> in short). This |
|
|
| 553 | is useful with <c>--pretend</c> to display a complete tree of dependencies for |
|
|
| 554 | any particular package. Without <c>--pretend</c>, <c>emerge</c> will (re)compile |
|
|
| 555 | all listed packages. However, <c>glibc</c> will <e>not</e> be listed as |
|
|
| 556 | dependency for safety reasons. |
|
|
| 557 | </p> |
262 | <p> |
| 558 | |
263 | However, a <brite>big warning</brite> applies: Portage will <e>not</e> check if |
| 559 | <pre caption="Show all dependencies of gnumeric"> |
264 | the package you want to remove is required by another package. It will however |
| 560 | # <i>emerge --emptytree --pretend gnumeric</i> |
265 | warn you when you want to remove an important package that breaks your system |
| 561 | </pre> |
266 | if you unmerge it. |
| 562 | |
|
|
| 563 | <p> |
267 | </p> |
| 564 | Another argument is <c>--nodeps</c>, which will ask Portage to try install the |
|
|
| 565 | given package without taking care of the dependencies. It is trivial that this |
|
|
| 566 | can lead to failures. |
|
|
| 567 | </p> |
|
|
| 568 | |
268 | |
| 569 | <pre caption="Installing gnumeric without taking care of the dependencies"> |
269 | <pre caption="Removing gnumeric from the system"> |
| 570 | # <i>emerge --nodeps gnumeric</i> |
270 | # <i>emerge --unmerge gnumeric</i> |
| 571 | </pre> |
271 | </pre> |
| 572 | |
272 | |
| 573 | <p> |
|
|
| 574 | The opposite of <c>--nodeps</c> is <c>--onlydeps</c>, which will have Portage |
|
|
| 575 | install all dependencies of a given package, but not the package itself: |
|
|
| 576 | </p> |
273 | <p> |
| 577 | |
274 | When you remove a package from your system, the dependencies of that package |
| 578 | <pre caption="Installing the dependencies of gnumeric"> |
275 | that were installed automatically when you installed the software are left. To |
| 579 | # <i>emerge --onlydeps gnumeric</i> |
276 | have Portage locate all dependencies that can now be removed, use |
|
|
277 | <c>emerge</c>'s <c>--depclean</c> functionality. We will talk about this later |
|
|
278 | on. |
| 580 | </pre> |
279 | </p> |
| 581 | |
280 | |
| 582 | </body> |
281 | </body> |
| 583 | </subsection> |
282 | </subsection> |
| 584 | <subsection> |
283 | <subsection> |
| 585 | <title>Updating your System</title> |
284 | <title>Updating your System</title> |
| 586 | <body> |
285 | <body> |
| 587 | |
286 | |
| 588 | <p> |
287 | <p> |
| 589 | Portage knows two special tags to denote a set of software packages: |
288 | To keep your system in perfect shape (and not to mention install the latest |
| 590 | <e>system</e> and <e>world</e>. You have already seen the former while |
289 | security updates) you need to update your system regularly. Since Portage only |
| 591 | installing Gentoo if you didn't use a <e>stage3</e> installation. To refresh |
290 | checks the ebuilds in your Portage tree you first have to update your Portage |
| 592 | things: <e>system</e> is the collection of <e>core</e> packages, necessary to |
291 | tree. When your Portage tree is updated, you can update your system with |
| 593 | have a working Gentoo system. |
292 | <c>emerge --update world</c>. In the next example, we'll also use the |
| 594 | </p> |
293 | <c>--ask</c> switch which will tell Portage to display the list of packages it |
| 595 | |
294 | wants to upgrade and ask you if you want to continue: |
| 596 | <p> |
295 | </p> |
| 597 | The <e>world</e> tag consists of all software you have installed yourself on |
296 | |
| 598 | your system plus the <e>system</e> information. In other words, every time you |
297 | <pre caption="Updating your system"> |
| 599 | emerge a package using <c>emerge <package-name></c>, the |
298 | # <i>emerge --update --ask world</i> |
| 600 | <c><package-name></c> is registered in the <e>world</e> file |
299 | </pre> |
| 601 | (<path>/var/cache/edb/world</path>). Dependencies are <e>not</e> part of the |
300 | |
| 602 | <e>world</e> file, but we will get to that later. |
|
|
| 603 | </p> |
301 | <p> |
| 604 | |
302 | Portage will then search for newer version of the applications you have |
|
|
303 | installed. However, it will only verify the versions for the applications you |
|
|
304 | have <e>explicitly</e> installed (the applications listed in |
|
|
305 | <path>/var/lib/portage/world</path>) - it does not thoroughly check their |
|
|
306 | dependencies. If you want to update the dependencies of those packages as well, |
|
|
307 | add the <c>--deep</c> argument: |
| 605 | <p> |
308 | </p> |
| 606 | If you want to update the system packages, use the <c>--update</c> option |
309 | |
| 607 | (<c>-u</c> in short): |
310 | <pre caption="Updating your system with dependencies"> |
|
|
311 | # <i>emerge --update --deep world</i> |
|
|
312 | </pre> |
|
|
313 | |
| 608 | </p> |
314 | <p> |
| 609 | |
315 | Still, this doesn't mean <e>all packages</e>: some packages on your system are |
| 610 | <pre caption="Updating the system packages"> |
316 | needed during the compile and build process of packages, but once that package |
| 611 | # <i>emerge --update system</i> |
317 | is installed, these dependencies are no longer required. Portage calls those |
| 612 | </pre> |
318 | <e>build dependencies</e>. To include those in an update cycle, add |
| 613 | |
319 | <c>--with-bdeps=y</c>: |
| 614 | <p> |
|
|
| 615 | An identical approach can be used for the world packages: |
|
|
| 616 | </p> |
320 | </p> |
| 617 | |
321 | |
| 618 | <pre caption="Updating your entire system"> |
322 | <pre caption="Updating your entire system"> |
| 619 | # <i>emerge --update world</i> |
323 | # <i>emerge --update --deep --with-bdeps=y world</i> |
| 620 | </pre> |
324 | </pre> |
| 621 | |
325 | |
| 622 | <p> |
|
|
| 623 | Again, if you want to see what <c>emerge</c> wants to update, use the |
|
|
| 624 | <c>--pretend</c> option together with the <c>--update</c> option: |
|
|
| 625 | </p> |
326 | <p> |
| 626 | |
327 | Since security updates also happen in packages you have not explicitly installed |
| 627 | <pre caption="Pretending to update your entire system"> |
328 | on your system (but that are pulled in as dependencies of other programs), it |
| 628 | # <i>emerge --pretend --update world</i> |
329 | is recommended to run this command once in a while. |
| 629 | <comment>(Some output removed to improve readability)</comment> |
|
|
| 630 | [ebuild U ] net-misc/wget-1.9-r1 [1.9] |
|
|
| 631 | [ebuild UD] media-video/dvdauthor-0.5.0 [0.5.3] |
|
|
| 632 | [ebuild U ] net-analyzer/ethereal-0.9.16 [0.9.14] |
|
|
| 633 | </pre> |
|
|
| 634 | |
|
|
| 635 | <p> |
330 | </p> |
| 636 | Right next to the word "ebuild" you will notice a letter (or combination of |
331 | |
| 637 | letters) which gives you more information about the package: |
332 | <p> |
|
|
333 | If you have altered any of your <uri link="?part=2&chap=2">USE flags</uri> |
|
|
334 | lately you might want to add <c>--newuse</c> as well. Portage will then verify |
|
|
335 | if the change requires the installation of new packages or recompilation of |
|
|
336 | existing ones: |
|
|
337 | </p> |
|
|
338 | |
|
|
339 | <pre caption="Performing a full update"> |
|
|
340 | # <i>emerge --update --deep --with-bdeps=y --newuse world</i> |
|
|
341 | </pre> |
|
|
342 | |
|
|
343 | </body> |
|
|
344 | </subsection> |
|
|
345 | <subsection> |
|
|
346 | <title>Metapackages</title> |
|
|
347 | <body> |
|
|
348 | |
|
|
349 | <p> |
|
|
350 | Some packages in the Portage tree don't have any real content but are used to |
|
|
351 | install a collection of packages. For instance, the <c>kde-meta</c> package will |
|
|
352 | install a complete KDE environment on your system by pulling in various |
|
|
353 | KDE-related packages as dependencies. |
|
|
354 | </p> |
|
|
355 | |
|
|
356 | <p> |
|
|
357 | If you ever want to remove such a package from your system, running <c>emerge |
|
|
358 | --unmerge</c> on the package won't have much effect as the dependencies remain |
|
|
359 | on the system. |
|
|
360 | </p> |
|
|
361 | |
|
|
362 | <p> |
|
|
363 | Portage has the functionality to remove orphaned dependencies as well, but since |
|
|
364 | the availability of software is dynamically dependent you first need to update |
|
|
365 | your entire system fully, including the new changes you applied when changing |
|
|
366 | USE flags. After this you can run <c>emerge --depclean</c> to remove the |
|
|
367 | orphaned dependencies. When this is done, you need to rebuild the applications |
|
|
368 | that were dynamically linked to the now-removed software titles but don't |
|
|
369 | require them anymore. |
|
|
370 | </p> |
|
|
371 | |
|
|
372 | <p> |
|
|
373 | All this is handled with the following three commands: |
|
|
374 | </p> |
|
|
375 | |
|
|
376 | <pre caption="Removing orphaned dependencies"> |
|
|
377 | # <i>emerge --update --deep --newuse world</i> |
|
|
378 | # <i>emerge --depclean</i> |
|
|
379 | # <i>revdep-rebuild</i> |
|
|
380 | </pre> |
|
|
381 | |
|
|
382 | <p> |
|
|
383 | <c>revdep-rebuild</c> is provided by the <c>gentoolkit</c> package; don't forget |
|
|
384 | to emerge it first: |
|
|
385 | </p> |
|
|
386 | |
|
|
387 | <pre caption="Installing the gentoolkit package"> |
|
|
388 | # <i>emerge gentoolkit</i> |
|
|
389 | </pre> |
|
|
390 | |
|
|
391 | </body> |
|
|
392 | </subsection> |
|
|
393 | </section> |
|
|
394 | <section id="license"> |
|
|
395 | <title>Licenses</title> |
|
|
396 | <subsection> |
|
|
397 | <body> |
|
|
398 | |
|
|
399 | <p> |
|
|
400 | Beginning with Portage version 2.1.7, you can accept or reject software |
|
|
401 | installation based on its license. All packages in the tree contain a |
|
|
402 | <c>LICENSE</c> entry in their ebuilds. Running <c>emerge --search |
|
|
403 | packagename</c> will tell you the package's license. |
|
|
404 | </p> |
|
|
405 | |
|
|
406 | <p> |
|
|
407 | By default, Portage permits all licenses, except End User License Agreements |
|
|
408 | (EULAs) that require reading and signing an acceptance agreement. |
|
|
409 | </p> |
|
|
410 | |
|
|
411 | <p> |
|
|
412 | The variable that controls permitted licenses is <c>ACCEPT_LICENSE</c>, which |
|
|
413 | can be set in <path>/etc/make.conf</path>: |
|
|
414 | </p> |
|
|
415 | |
|
|
416 | <pre caption="Default ACCEPT_LICENSE in /etc/make.conf"> |
|
|
417 | ACCEPT_LICENSE="* -@EULA" |
|
|
418 | </pre> |
|
|
419 | |
|
|
420 | <p> |
|
|
421 | With this configuration, packages that require interaction during installation |
|
|
422 | to approve their EULA <e>will not</e> be installed. Packages without an EULA |
|
|
423 | <e>will</e> be installed. |
|
|
424 | </p> |
|
|
425 | |
|
|
426 | <p> |
|
|
427 | You can set <c>ACCEPT_LICENSE</c> globally in <path>/etc/make.conf</path>, or |
|
|
428 | you can specify it on a per-package basis in |
|
|
429 | <path>/etc/portage/package.license</path>. |
|
|
430 | </p> |
|
|
431 | |
|
|
432 | <p> |
|
|
433 | For example, if you want to allow the <c>truecrypt-2.7</c> license for |
|
|
434 | <c>app-crypt/truecrypt</c>, add the following to |
|
|
435 | <path>/etc/portage/package.license</path>: |
|
|
436 | </p> |
|
|
437 | |
|
|
438 | <pre caption="Specifying a truecrypt license in package.license"> |
|
|
439 | app-crypt/truecrypt truecrypt-2.7 |
|
|
440 | </pre> |
|
|
441 | |
|
|
442 | <p> |
|
|
443 | This permits installation of truecrypt versions that have the |
|
|
444 | <c>truecrypt-2.7</c> license, but not versions with the <c>truecrypt-2.8</c> |
|
|
445 | license. |
|
|
446 | </p> |
|
|
447 | |
|
|
448 | <impo> |
|
|
449 | Licenses are stored in <path>/usr/portage/licenses</path>, and license groups |
|
|
450 | are kept in <path>/usr/portage/profiles/license_groups</path>. The first entry |
|
|
451 | of each line in CAPITAL letters is the name of the license group, and every |
|
|
452 | entry after that is an individual license. |
|
|
453 | </impo> |
|
|
454 | |
|
|
455 | <p> |
|
|
456 | License groups defined in <c>ACCEPT_LICENSE</c> are prefixed with an <b>@</b> |
|
|
457 | sign. Here's an example of a system that globally permits the GPL-compatible |
|
|
458 | license group, as well as a few other groups and individual licenses: |
|
|
459 | </p> |
|
|
460 | |
|
|
461 | <pre caption="ACCEPT_LICENSE in /etc/make.conf"> |
|
|
462 | ACCEPT_LICENSE="@GPL-COMPATIBLE @OSI-APPROVED @EULA atheros-hal BitstreamVera" |
|
|
463 | </pre> |
|
|
464 | |
|
|
465 | <p> |
|
|
466 | If you want only free software and documentation on your system, you might use |
|
|
467 | the following setup: |
|
|
468 | </p> |
|
|
469 | |
|
|
470 | <pre caption="Use only free licenses"> |
|
|
471 | ACCEPT_LICENSE="-* @FREE" |
|
|
472 | </pre> |
|
|
473 | |
|
|
474 | <p> |
|
|
475 | In this case, "free" is mostly defined by the <uri |
|
|
476 | link="http://www.gnu.org/philosophy/free-sw.html">FSF</uri> and <uri |
|
|
477 | link="http://www.opensource.org/docs/osd">OSI</uri>. Any package whose license |
|
|
478 | does not meet these requirements will not be installed on your system. |
|
|
479 | </p> |
|
|
480 | |
|
|
481 | </body> |
|
|
482 | </subsection> |
|
|
483 | </section> |
|
|
484 | <section> |
|
|
485 | <title>When Portage is Complaining...</title> |
|
|
486 | <subsection> |
|
|
487 | <title>About SLOTs, Virtuals, Branches, Architectures and Profiles</title> |
|
|
488 | <body> |
|
|
489 | |
|
|
490 | <p> |
|
|
491 | As we stated before, Portage is extremely powerful and supports many features |
|
|
492 | that other software management tools lack. To understand this, we explain a few |
|
|
493 | aspects of Portage without going into too much detail. |
|
|
494 | </p> |
|
|
495 | |
|
|
496 | <p> |
|
|
497 | With Portage different versions of a single package can coexist on a system. |
|
|
498 | While other distributions tend to name their package to those versions (like |
|
|
499 | <c>freetype</c> and <c>freetype2</c>) Portage uses a technology called |
|
|
500 | <e>SLOT</e>s. An ebuild declares a certain SLOT for its version. Ebuilds with |
|
|
501 | different SLOTs can coexist on the same system. For instance, the |
|
|
502 | <c>freetype</c> package has ebuilds with <c>SLOT="1"</c> and <c>SLOT="2"</c>. |
|
|
503 | </p> |
|
|
504 | |
|
|
505 | <p> |
|
|
506 | There are also packages that provide the same functionality but are implemented |
|
|
507 | differently. For instance, <c>metalogd</c>, <c>sysklogd</c> and <c>syslog-ng</c> |
|
|
508 | are all system loggers. Applications that rely on the availability of "a system |
|
|
509 | logger" cannot depend on, for instance, <c>metalogd</c>, as the other system |
|
|
510 | loggers are as good a choice as any. Portage allows for <e>virtuals</e>: each |
|
|
511 | system logger provides <c>virtual/syslog</c> so that applications can depend on |
|
|
512 | <c>virtual/syslog</c>. |
|
|
513 | </p> |
|
|
514 | |
|
|
515 | <p> |
|
|
516 | Software in the Portage tree can reside in different branches. By default your |
|
|
517 | system only accepts packages that Gentoo deems stable. Most new software titles, |
|
|
518 | when committed, are added to the testing branch, meaning more testing needs to |
|
|
519 | be done before it is marked as stable. Although you will see the ebuilds for |
|
|
520 | those software in the Portage tree, Portage will not update them before they are |
|
|
521 | placed in the stable branch. |
|
|
522 | </p> |
|
|
523 | |
|
|
524 | <p> |
|
|
525 | Some software is only available for a few architectures. Or the software doesn't |
|
|
526 | work on the other architectures, or it needs more testing, or the developer that |
|
|
527 | committed the software to the Portage tree is unable to verify if the package |
|
|
528 | works on different architectures. |
|
|
529 | </p> |
|
|
530 | |
|
|
531 | <p> |
|
|
532 | Each Gentoo installation adheres to a certain <c>profile</c> which contains, |
|
|
533 | amongst other information, the list of packages that are required for a system |
|
|
534 | to function normally. |
|
|
535 | </p> |
|
|
536 | |
|
|
537 | </body> |
|
|
538 | </subsection> |
|
|
539 | <subsection id="blocked"> |
|
|
540 | <title>Blocked Packages</title> |
|
|
541 | <body> |
|
|
542 | |
|
|
543 | <pre caption="Portage warning about blocked packages (with --pretend)"> |
|
|
544 | [blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1) |
|
|
545 | </pre> |
|
|
546 | |
|
|
547 | <pre caption="Portage warning about blocked packages (without --pretend)"> |
|
|
548 | !!! Error: the mail-mta/postfix package conflicts with another package. |
|
|
549 | !!! both can't be installed on the same system together. |
|
|
550 | !!! Please use 'emerge --pretend' to determine blockers. |
|
|
551 | </pre> |
|
|
552 | |
|
|
553 | <p> |
|
|
554 | Ebuilds contain specific fields that inform Portage about its dependencies. |
|
|
555 | There are two possible dependencies: build dependencies, declared in |
|
|
556 | <c>DEPEND</c> and run-time dependencies, declared in <c>RDEPEND</c>. When one of |
|
|
557 | these dependencies explicitly marks a package or virtual as being <e>not</e> |
|
|
558 | compatible, it triggers a blockage. |
|
|
559 | </p> |
|
|
560 | |
|
|
561 | <p> |
|
|
562 | While recent versions of Portage are smart enough to work around minor blockages |
|
|
563 | without user intervention, occasionally you will need to fix it yourself, as |
|
|
564 | explained below. |
|
|
565 | </p> |
|
|
566 | |
|
|
567 | <p> |
|
|
568 | To fix a blockage, you can choose to not install the package or unmerge the |
|
|
569 | conflicting package first. In the given example, you can opt not to install |
|
|
570 | <c>postfix</c> or to remove <c>ssmtp</c> first. |
|
|
571 | </p> |
|
|
572 | |
|
|
573 | <p> |
|
|
574 | You may also see blocking packages with specific atoms, such as |
|
|
575 | <b><</b>media-video/mplayer-1.0_rc1-r2. In this case, updating to a more |
|
|
576 | recent version of the blocking package would remove the block. |
|
|
577 | </p> |
|
|
578 | |
|
|
579 | <p> |
|
|
580 | It is also possible that two packages that are yet to be installed are blocking |
|
|
581 | each other. In this rare case, you should find out why you need to install both. |
|
|
582 | In most cases you can do with one of the packages alone. If not, please file a |
|
|
583 | bug on <uri link="http://bugs.gentoo.org">Gentoo's bugtracking system</uri>. |
|
|
584 | </p> |
|
|
585 | |
|
|
586 | </body> |
|
|
587 | </subsection> |
|
|
588 | <subsection id="masked"> |
|
|
589 | <title>Masked Packages</title> |
|
|
590 | <body> |
|
|
591 | |
|
|
592 | <pre caption="Portage warning about masked packages"> |
|
|
593 | !!! all ebuilds that could satisfy "bootsplash" have been masked. |
|
|
594 | </pre> |
|
|
595 | |
|
|
596 | <pre caption="Portage warning about masked packages - reason"> |
|
|
597 | !!! possible candidates are: |
|
|
598 | |
|
|
599 | - gnome-base/gnome-2.8.0_pre1 (masked by: <i>~x86 keyword</i>) |
|
|
600 | - lm-sensors/lm-sensors-2.8.7 (masked by: <i>-sparc keyword</i>) |
|
|
601 | - sys-libs/glibc-2.3.4.20040808 (masked by: <i>-* keyword</i>) |
|
|
602 | - dev-util/cvsd-1.0.2 (masked by: <i>missing keyword</i>) |
|
|
603 | - games-fps/unreal-tournament-451 (masked by: <i>package.mask</i>) |
|
|
604 | - sys-libs/glibc-2.3.2-r11 (masked by: <i>profile</i>) |
|
|
605 | - net-im/skype-2.1.0.81 (masked by: skype-eula <i>license</i>(s)) |
|
|
606 | </pre> |
|
|
607 | |
|
|
608 | <p> |
|
|
609 | When you want to install a package that isn't available for your system, you |
|
|
610 | will receive this masking error. You should try installing a different |
|
|
611 | application that is available for your system or wait until the package is put |
|
|
612 | available. There is always a reason why a package is masked: |
| 638 | </p> |
613 | </p> |
| 639 | |
614 | |
| 640 | <ul> |
615 | <ul> |
| 641 | <li> |
616 | <li> |
| 642 | <e>B</e> (blocks) The package listed to the left is blocking the emerge of |
617 | <b>~arch keyword</b> means that the application is not tested sufficiently |
| 643 | the package listed to the right |
618 | to be put in the stable branch. Wait a few days or weeks and try again. |
| 644 | </li> |
619 | </li> |
| 645 | <li> |
620 | <li> |
| 646 | <e>N</e> (new) The package is new to your system and will be emerged for the |
621 | <b>-arch keyword</b> or <b>-* keyword</b> means that the application does |
| 647 | first time |
622 | not work on your architecture. If you believe the package does work file |
|
|
623 | a bug at our <uri link="http://bugs.gentoo.org">bugzilla</uri> website. |
| 648 | </li> |
624 | </li> |
| 649 | <li> |
625 | <li> |
| 650 | <e>R</e> (reemerge) The package isn't new, but needs to be reemerged |
626 | <b>missing keyword</b> means that the application has not been tested on |
|
|
627 | your architecture yet. Ask the architecture porting team to test the package |
|
|
628 | or test it for them and report your findings on our <uri |
|
|
629 | link="http://bugs.gentoo.org">bugzilla</uri> website. |
| 651 | </li> |
630 | </li> |
| 652 | <li> |
631 | <li> |
| 653 | <e>F</e> (fetch) The package requires that you download the source code |
632 | <b>package.mask</b> means that the package has been found corrupt, unstable |
| 654 | manually (for instance due to licencing issues) |
633 | or worse and has been deliberately marked as do-not-use. |
| 655 | </li> |
634 | </li> |
| 656 | <li> |
635 | <li> |
| 657 | <e>U</e> (update) The package already exists on your system but will be |
636 | <b>profile</b> means that the package has been found not suitable for your |
| 658 | upgraded |
637 | profile. The application might break your system if you installed it or is |
|
|
638 | just not compatible with the profile you use. |
| 659 | </li> |
639 | </li> |
| 660 | <li> |
640 | <li> |
| 661 | <e>UD</e> (downgrade) The package already exists on your system but will be |
641 | <b>license</b> means that the package's license is not compatible with your |
| 662 | downgraded |
642 | <c>ACCEPT_LICENSE</c> setting. You must explicitly permit its license or |
| 663 | </li> |
643 | license group by setting it in <path>/etc/make.conf</path> or in |
| 664 | <li> |
644 | <path>/etc/portage/package.license</path>. Refer to <uri |
| 665 | <e>U-</e> (slot warning) The package you have installed on your system |
645 | link="#license">Licenses</uri> to learn how licenses work. |
| 666 | is listed as a package that can not coexist with a different version, but |
|
|
| 667 | your update does. The update will be installed and the older version will be |
|
|
| 668 | removed. |
|
|
| 669 | </li> |
646 | </li> |
| 670 | </ul> |
647 | </ul> |
| 671 | |
648 | |
| 672 | <p> |
|
|
| 673 | In certain cases, an update may mean a downgrade (i.e. install an older version |
|
|
| 674 | instead of a newer version). If you don't want this to happen, use the |
|
|
| 675 | <c>--upgradeonly</c> option (<c>-U</c> in short): |
|
|
| 676 | </p> |
|
|
| 677 | |
|
|
| 678 | <pre caption="Upgrading your entire system"> |
|
|
| 679 | # <i>emerge --update --upgradeonly world</i> |
|
|
| 680 | </pre> |
|
|
| 681 | |
|
|
| 682 | <p> |
|
|
| 683 | Of course, we are talking here about <e>system</e> and <e>world</e>, but you can |
|
|
| 684 | perform the same actions for individual software packages. |
|
|
| 685 | </p> |
|
|
| 686 | |
|
|
| 687 | </body> |
649 | </body> |
| 688 | </subsection> |
|
|
| 689 | <subsection> |
650 | </subsection> |
| 690 | <title>Removing Software</title> |
651 | <subsection id="USEdependency"> |
| 691 | <body> |
652 | <title>Necessary USE Flag Changes</title> |
| 692 | |
|
|
| 693 | <p> |
|
|
| 694 | If you want to remove software from your system, you can use the <c>unmerge</c> |
|
|
| 695 | option (<c>-C</c> - capital C - in short): |
|
|
| 696 | </p> |
|
|
| 697 | |
|
|
| 698 | <pre caption="Uninstalling software"> |
|
|
| 699 | # <i>emerge unmerge gnumeric</i> |
|
|
| 700 | </pre> |
|
|
| 701 | |
|
|
| 702 | <p> |
|
|
| 703 | If you want to test a removal (but not perform it), you can use <c>--pretend</c> |
|
|
| 704 | again: |
|
|
| 705 | </p> |
|
|
| 706 | |
|
|
| 707 | <pre caption="Pretending to uninstall software"> |
|
|
| 708 | # <i>emerge --pretend unmerge gnumeric</i> |
|
|
| 709 | </pre> |
|
|
| 710 | |
|
|
| 711 | <warn> |
|
|
| 712 | Portage doesn't verify if a package is a dependency for another |
|
|
| 713 | installed package. It also doesn't warn you if the package is part of |
|
|
| 714 | <e>system</e>, i.e. a core application necessary for the correct functioning of |
|
|
| 715 | your system! |
|
|
| 716 | </warn> |
|
|
| 717 | |
|
|
| 718 | <p> |
|
|
| 719 | Once the unmerge begins you will see a long list of filenames belonging to the |
|
|
| 720 | package. Some of these filenames will have a flag displayed to the |
|
|
| 721 | left of the filename. The flags <c>!mtime</c>, <c>!empty</c>, and <c>cfgpro</c> |
|
|
| 722 | specify reasons why certain files are not being removed while the package is. |
|
|
| 723 | Files listed without any of these three flags are removed from the |
|
|
| 724 | filesystem successfully. The three flags specify the following reasons: |
|
|
| 725 | </p> |
|
|
| 726 | |
|
|
| 727 | <ul> |
|
|
| 728 | <li> |
|
|
| 729 | <c>!mtime</c> : The listed file has been changed since it was installed, |
|
|
| 730 | probably by you or some tool |
|
|
| 731 | </li> |
|
|
| 732 | <li> |
|
|
| 733 | <c>!empty</c> : The listed directory is not empty |
|
|
| 734 | </li> |
|
|
| 735 | <li> |
|
|
| 736 | <c>cfgpro</c> : This file is located inside a protected directory and will |
|
|
| 737 | not be touched for safety |
|
|
| 738 | </li> |
|
|
| 739 | </ul> |
|
|
| 740 | |
|
|
| 741 | </body> |
653 | <body> |
| 742 | </subsection> |
654 | |
| 743 | </section> |
655 | <pre caption="Portage warning about USE flag change requirement"> |
| 744 | <section> |
656 | The following USE changes are necessary to proceed: |
| 745 | <title>Software Availability</title> |
657 | #required by app-text/happypackage-2.0, required by happypackage (argument) |
|
|
658 | >=app-text/feelings-1.0.0 test |
|
|
659 | </pre> |
|
|
660 | |
|
|
661 | <p> |
|
|
662 | The error message might also be displayed as follows, if <c>--autounmask</c> |
|
|
663 | isn't set: |
|
|
664 | </p> |
|
|
665 | |
|
|
666 | <pre caption="Portage error about USE flag change requirement"> |
|
|
667 | emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]". |
|
|
668 | !!! One of the following packages is required to complete your request: |
|
|
669 | - app-text/feelings-1.0.0 (Change USE: +test) |
|
|
670 | (dependency required by "app-text/happypackage-2.0" [ebuild]) |
|
|
671 | (dependency required by "happypackage" [argument]) |
|
|
672 | </pre> |
|
|
673 | |
|
|
674 | <p> |
|
|
675 | Such warning or error occurs when you want to install a package which not only |
|
|
676 | depends on another package, but also requires that that package is built with a |
|
|
677 | particular USE flag (or set of USE flags). In the given example, the package |
|
|
678 | <c>app-text/feelings</c> needs to be built with <c>USE="test"</c>, but this USE |
|
|
679 | flag is not set on the system. |
|
|
680 | </p> |
|
|
681 | |
|
|
682 | <p> |
|
|
683 | To resolve this, either add the requested USE flag to your global USE flags in |
|
|
684 | <path>/etc/make.conf</path>, or set it for the specific package in |
|
|
685 | <path>/etc/portage/package.use</path>. |
|
|
686 | </p> |
|
|
687 | |
|
|
688 | </body> |
| 746 | <subsection> |
689 | </subsection> |
| 747 | <title>ARCH or not?</title> |
690 | <subsection id="missingdependencies"> |
| 748 | <body> |
691 | <title>Missing Dependencies</title> |
| 749 | |
|
|
| 750 | <p> |
|
|
| 751 | Gentoo places its packages in two possible stadia called <e>ARCH</e> and |
|
|
| 752 | <e>~ARCH</e>. Don't take this literally: the stadia depend on the architecture |
|
|
| 753 | you are using. In other words, for x86-based systems you have <e>x86</e> and |
|
|
| 754 | <e>~x86</e>, for ppc-based systems you have <e>ppc</e> and <e>~ppc</e> etc. |
|
|
| 755 | </p> |
|
|
| 756 | |
|
|
| 757 | <p> |
|
|
| 758 | The <e>~ARCH</e> stadium means that the package works for the developer in |
|
|
| 759 | charge of the package, but that the package hasn't been tested thoroughly enough |
|
|
| 760 | by the community to be placed in <e>ARCH</e>. <e>~ARCH</e> packages usually go |
|
|
| 761 | to <e>ARCH</e> after being bugfree for a sufficient amount of time. |
|
|
| 762 | </p> |
|
|
| 763 | |
|
|
| 764 | <p> |
|
|
| 765 | Your system will use <e>ARCH</e> packages per default. If you want to live on |
|
|
| 766 | the edge, don't mind having a broken package once in a while, and you like |
|
|
| 767 | submitting bugreports to <uri |
|
|
| 768 | link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, then you can opt to use |
|
|
| 769 | <e>~ARCH</e> packages. To "move" your system to a <e>~ARCH</e>-using system, |
|
|
| 770 | edit the <c>ACCEPT_KEYWORDS</c> variable in <path>/etc/make.conf</path> so that |
|
|
| 771 | it reads <e>~ARCH</e> (again: for x86-based systems: <e>~x86</e>, etc.). |
|
|
| 772 | </p> |
|
|
| 773 | |
|
|
| 774 | <p> |
|
|
| 775 | If you want to update your system now, you will notice that <e>a lot</e> of |
|
|
| 776 | packages will be updated! |
|
|
| 777 | </p> |
|
|
| 778 | |
|
|
| 779 | </body> |
692 | <body> |
| 780 | </subsection> |
693 | |
|
|
694 | <pre caption="Portage warning about missing dependency"> |
|
|
695 | emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4". |
|
|
696 | |
|
|
697 | !!! Problem with ebuild sys-devel/gcc-3.4.2-r2 |
|
|
698 | !!! Possibly a DEPEND/*DEPEND problem. |
|
|
699 | </pre> |
|
|
700 | |
|
|
701 | <p> |
|
|
702 | The application you are trying to install depends on another package that is not |
|
|
703 | available for your system. Please check <uri |
|
|
704 | link="http://bugs.gentoo.org">bugzilla</uri> if the issue is known and if not, |
|
|
705 | please report it. Unless you are mixing branches this should not occur and is |
|
|
706 | therefore a bug. |
|
|
707 | </p> |
|
|
708 | |
|
|
709 | </body> |
| 781 | <subsection> |
710 | </subsection> |
| 782 | <title>Masked Packages</title> |
711 | <subsection id="ambiguousebuild"> |
| 783 | <body> |
712 | <title>Ambiguous Ebuild Name</title> |
| 784 | |
|
|
| 785 | <p> |
|
|
| 786 | When you want to install a package, you might come across the following message: |
|
|
| 787 | </p> |
|
|
| 788 | |
|
|
| 789 | <pre caption="Message about masked packages"> |
|
|
| 790 | Calculating dependencies |
|
|
| 791 | !!! <comment>all ebuilds that could satisfy </comment><your package><comment> have been masked.</comment> |
|
|
| 792 | </pre> |
|
|
| 793 | |
|
|
| 794 | <p> |
|
|
| 795 | A package can be masked due to two reasons: |
|
|
| 796 | </p> |
|
|
| 797 | |
|
|
| 798 | <ol> |
|
|
| 799 | <li>The package is in <e>~ARCH</e> while you use <e>ARCH</e></li> |
|
|
| 800 | <li>The package is hard-masked explicitly</li> |
|
|
| 801 | </ol> |
|
|
| 802 | |
|
|
| 803 | <p> |
|
|
| 804 | If the package is masked because of the first reason, and you <e>really</e> want |
|
|
| 805 | to install it (knowing that there <e>is</e> a reason why it isn't available in |
|
|
| 806 | <e>ARCH</e>), you can temporarily accept <e>~ARCH</e> packages: |
|
|
| 807 | </p> |
|
|
| 808 | |
|
|
| 809 | <pre caption="Temporarily accepting ~ARCH packages"> |
|
|
| 810 | # <i>ACCEPT_KEYWORDS="~x86" emerge gnumeric</i> |
|
|
| 811 | </pre> |
|
|
| 812 | |
|
|
| 813 | <p> |
|
|
| 814 | A package is hardmasked if it is listed in |
|
|
| 815 | <path>/usr/portage/profiles/package.mask</path>. If you read this file, you |
|
|
| 816 | will also read the reason why the package is hardmasked (it is usually added as |
|
|
| 817 | a comment). If you want to install the package nevertheless (despite all the |
|
|
| 818 | possible warnings we could ever throw at your head about "breaking your system", |
|
|
| 819 | "breaks other packages", or "badly needs testing"), create the |
|
|
| 820 | <path>/etc/portage/package.unmask</path> file and list the package in it (use |
|
|
| 821 | the same format as is used in <path>/usr/portage/profiles/package.mask</path>). |
|
|
| 822 | </p> |
|
|
| 823 | |
|
|
| 824 | <p> |
|
|
| 825 | Do <e>not</e> alter the <path>/usr/portage/profiles/package.mask</path> file as |
|
|
| 826 | all changes are undone the next time you update your Portage tree. If you want |
|
|
| 827 | to hardmask a package create <path>/etc/portage/package.mask</path> and list the |
|
|
| 828 | package in it (use the same format as mentioned above). |
|
|
| 829 | </p> |
|
|
| 830 | |
|
|
| 831 | <p> |
|
|
| 832 | Another trick to circumvent the "masked package" problem is to install the |
|
|
| 833 | package using the full path. This will ignore both the <c>ACCEPT_KEYWORD</c> |
|
|
| 834 | settings and the <path>package.mask</path> listing. |
|
|
| 835 | </p> |
|
|
| 836 | |
|
|
| 837 | <pre caption="Installing a package without checking for stadium / masking"> |
|
|
| 838 | # <i>emerge /usr/portage/app-office/gnumeric/gnumeric-1.2.0.ebuild</i> |
|
|
| 839 | </pre> |
|
|
| 840 | |
|
|
| 841 | </body> |
713 | <body> |
| 842 | </subsection> |
714 | |
|
|
715 | <pre caption="Portage warning about ambiguous ebuild names"> |
|
|
716 | [ Results for search key : listen ] |
|
|
717 | [ Applications found : 2 ] |
|
|
718 | |
|
|
719 | * dev-tinyos/listen [ Masked ] |
|
|
720 | Latest version available: 1.1.15 |
|
|
721 | Latest version installed: [ Not Installed ] |
|
|
722 | Size of files: 10,032 kB |
|
|
723 | Homepage: http://www.tinyos.net/ |
|
|
724 | Description: Raw listen for TinyOS |
|
|
725 | License: BSD |
|
|
726 | |
|
|
727 | * media-sound/listen [ Masked ] |
|
|
728 | Latest version available: 0.6.3 |
|
|
729 | Latest version installed: [ Not Installed ] |
|
|
730 | Size of files: 859 kB |
|
|
731 | Homepage: http://www.listen-project.org |
|
|
732 | Description: A Music player and management for GNOME |
|
|
733 | License: GPL-2 |
|
|
734 | |
|
|
735 | !!! The short ebuild name "listen" is ambiguous. Please specify |
|
|
736 | !!! one of the above fully-qualified ebuild names instead. |
|
|
737 | </pre> |
|
|
738 | |
|
|
739 | <p> |
|
|
740 | The application you want to install has a name that corresponds with more than |
|
|
741 | one package. You need to supply the category name as well. Portage will inform |
|
|
742 | you of possible matches to choose from. |
|
|
743 | </p> |
|
|
744 | |
|
|
745 | </body> |
| 843 | <subsection> |
746 | </subsection> |
| 844 | <title>Blocked Packages</title> |
747 | <subsection id="circulardependencies"> |
|
|
748 | <title>Circular Dependencies</title> |
|
|
749 | <body> |
|
|
750 | |
|
|
751 | <pre caption="Portage warning about circular dependencies"> |
|
|
752 | !!! Error: circular dependencies: |
|
|
753 | |
|
|
754 | ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1 |
|
|
755 | ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 |
|
|
756 | </pre> |
|
|
757 | |
|
|
758 | <p> |
|
|
759 | Two (or more) packages you want to install depend on each other and can |
|
|
760 | therefore not be installed. This is most likely a bug in the Portage tree. |
|
|
761 | Please resync after a while and try again. You can also check <uri |
|
|
762 | link="http://bugs.gentoo.org">bugzilla</uri> if the issue is known and if not, |
|
|
763 | report it. |
|
|
764 | </p> |
|
|
765 | |
| 845 | <body> |
766 | </body> |
|
|
767 | </subsection> |
|
|
768 | <subsection id="fetchfailed"> |
|
|
769 | <title>Fetch failed</title> |
|
|
770 | <body> |
| 846 | |
771 | |
| 847 | <p> |
772 | <pre caption="Portage warning about fetch failed"> |
| 848 | You have a situation when you receive the following error on your screen: |
773 | !!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing... |
|
|
774 | <comment>(...)</comment> |
|
|
775 | !!! Some fetch errors were encountered. Please see above for details. |
|
|
776 | </pre> |
|
|
777 | |
| 849 | </p> |
778 | <p> |
| 850 | |
779 | Portage was unable to download the sources for the given application and will |
| 851 | <pre caption="Blocking package"> |
780 | try to continue installing the other applications (if applicable). This failure |
| 852 | [blocks B ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0) |
781 | can be due to a mirror that has not synchronised correctly or because the ebuild |
| 853 | </pre> |
782 | points to an incorrect location. The server where the sources reside can also be |
| 854 | |
783 | down for some reason. |
| 855 | <p> |
784 | </p> |
| 856 | In the above example, the package <c>bonobo-activation</c> is blocking the |
785 | |
| 857 | emerge of <c>libbonobo</c>. To resolve this issue, remove the |
|
|
| 858 | <c>bonobo-activation</c> package and continue: |
|
|
| 859 | </p> |
786 | <p> |
| 860 | |
787 | Retry after one hour to see if the issue still persists. |
| 861 | <pre caption="Resolving a blocking situation"> |
|
|
| 862 | # <i>emerge unmerge bonobo-activation</i> |
|
|
| 863 | </pre> |
788 | </p> |
|
|
789 | |
|
|
790 | </body> |
|
|
791 | </subsection> |
|
|
792 | <subsection id="profileprotect"> |
|
|
793 | <title>System Profile Protection</title> |
|
|
794 | <body> |
|
|
795 | |
|
|
796 | <pre caption="Portage warning about profile-protected package"> |
|
|
797 | !!! Trying to unmerge package(s) in system profile. 'sys-apps/portage' |
|
|
798 | !!! This could be damaging to your system. |
|
|
799 | </pre> |
|
|
800 | |
|
|
801 | <p> |
|
|
802 | You have asked to remove a package that is part of your system's core packages. |
|
|
803 | It is listed in your profile as required and should therefore not be removed |
|
|
804 | from the system. |
|
|
805 | </p> |
|
|
806 | |
|
|
807 | </body> |
|
|
808 | </subsection> |
|
|
809 | <subsection id="digesterror"> |
|
|
810 | <title>Digest Verification Failures</title> |
|
|
811 | <body> |
|
|
812 | |
|
|
813 | <p> |
|
|
814 | Sometimes, when you attempt to emerge a package, it will fail with the message: |
|
|
815 | </p> |
|
|
816 | |
|
|
817 | <pre caption="Digest verification failure"> |
|
|
818 | >>> checking ebuild checksums |
|
|
819 | !!! Digest verification failed: |
|
|
820 | </pre> |
|
|
821 | |
|
|
822 | <p> |
|
|
823 | This is a sign that something is wrong with the Portage tree -- often, it is |
|
|
824 | because a developer may have made a mistake when committing a package to the |
|
|
825 | tree. |
|
|
826 | </p> |
|
|
827 | |
|
|
828 | <p> |
|
|
829 | When the digest verification fails, do <e>not</e> try to re-digest the package |
|
|
830 | yourself. Running <c>ebuild foo manifest</c> will not fix the problem; it will |
|
|
831 | almost certainly make it worse! |
|
|
832 | </p> |
|
|
833 | |
|
|
834 | <p> |
|
|
835 | Instead, wait an hour or two for the tree to settle down. It's likely that the |
|
|
836 | error was noticed right away, but it can take a little time for the fix to |
|
|
837 | trickle down the Portage tree. While you're waiting, check <uri |
|
|
838 | link="http://bugs.gentoo.org">Bugzilla</uri> and see if anyone has reported |
|
|
839 | the problem yet. If not, go ahead and file a bug for the broken package. |
|
|
840 | </p> |
|
|
841 | |
|
|
842 | <p> |
|
|
843 | Once you see that the bug has been fixed, you may want to re-sync to pick up |
|
|
844 | the fixed digest. |
|
|
845 | </p> |
|
|
846 | |
|
|
847 | <impo> |
|
|
848 | This does <e>not</e> mean that you can re-sync your tree multiple times! As |
|
|
849 | stated in the rsync policy (when you run <c>emerge --sync</c>), users who sync |
|
|
850 | too often will be banned! In fact, it's better to just wait until your next |
|
|
851 | scheduled sync, so that you don't overload the rsync servers. |
|
|
852 | </impo> |
| 864 | |
853 | |
| 865 | </body> |
854 | </body> |
| 866 | </subsection> |
855 | </subsection> |
| 867 | </section> |
856 | </section> |
| 868 | </sections> |
857 | </sections> |