/[gentoo]/xml/htdocs/doc/en/handbook/hb-working-portage.xml
Gentoo

Contents of /xml/htdocs/doc/en/handbook/hb-working-portage.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.33 - (hide annotations) (download) (as text)
Mon Aug 23 15:33:29 2004 UTC (10 years, 1 month ago) by neysx
Branch: MAIN
Changes since 1.32: +4 -4 lines
File MIME type: application/xml
Typo s/thay/that/

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 &lt;foser@gentoo.org&gt; gnumeric-1.2.2.ebuild :
258     New release, requested in #34492
259     updated deps
260    
261     12 Nov 2003; Jason Wever &lt;weeve@gentoo.org&gt; gnumeric-1.2.0.ebuild:
262     Marked stable on sparc, fixes bug #32405.
263    
264     14 Oct 2003; Jason Wever &lt;weeve@gentoo.org&gt; 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> &amp; <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 &lt;package-name&gt;</c> or <c>emerge
396     &lt;category&gt;/&lt;package-name&gt;</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 "&lt;gnumeric-1.2"</i>
442     </pre>
443    
444     <p>
445 swift 1.4 Other possibilities are of course "&gt;" (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 "&lt;gnumeric-1.2"</i>
525     </pre>
526    
527     <p>
528 swift 1.4 Other possibilities are of course "&gt;" (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 &lt;package-name&gt;</c>, the
595     <c>&lt;package-name&gt;</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>&lt;your package&gt;<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" &gt;&gt; /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" &gt;&gt; /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 "&gt;app-office/gnumeric-1.2.10" &gt;&gt; /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>

  ViewVC Help
Powered by ViewVC 1.1.20