/[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.34 - (hide annotations) (download) (as text)
Sat Aug 28 11:30:43 2004 UTC (9 years, 11 months ago) by swift
Branch: MAIN
Changes since 1.33: +21 -1 lines
File MIME type: application/xml
#60176 - Adding SLOT and depclean to the Gentoo Handbook

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 swift 1.34 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.33 2004/08/23 15:33:29 neysx 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 swift 1.34 <p>
578     When you uninstall software Portage will not automatically unmerge the
579     dependencies that aren't needed anymore. If you want to "clean" your system from
580     those orphaned dependencies, you can use <c>emerge depclean</c>. This will
581     search for all installed software that you haven't installed explicitly and that
582     isn't a dependency of software that you have installed explicitly.
583     </p>
584    
585     <warn>
586     Using depclean can seriously impair your system. Use with caution and
587     double-check the list of dependencies that Portage wants to remove before you go
588     ahead!
589     </warn>
590    
591     <pre caption="Listing and removing the orphaned dependencies">
592     # <i>emerge -p depclean</i>
593     <comment>(After seriously verifying the list, remove the orphaned dependencies)</comment>
594     # <i>emerge depclean</i>
595     </pre>
596    
597 swift 1.11 </body>
598     </subsection>
599     <subsection>
600 swift 1.3 <title>Updating your System</title>
601 swift 1.1 <body>
602    
603 swift 1.3 <p>
604     Portage knows two special tags to denote a set of software packages:
605     <e>system</e> and <e>world</e>. You have already seen the former while
606     installing Gentoo if you didn't use a <e>stage3</e> installation. To refresh
607     things: <e>system</e> is the collection of <e>core</e> packages, necessary to
608     have a working Gentoo system.
609     </p>
610    
611     <p>
612     The <e>world</e> tag consists of all software you have installed yourself on
613     your system plus the <e>system</e> information. In other words, every time you
614     emerge a package using <c>emerge &lt;package-name&gt;</c>, the
615     <c>&lt;package-name&gt;</c> is registered in the <e>world</e> file
616     (<path>/var/cache/edb/world</path>). Dependencies are <e>not</e> part of the
617     <e>world</e> file, but we will get to that later.
618     </p>
619    
620     <p>
621     If you want to update the system packages, use the <c>--update</c> option
622     (<c>-u</c> in short):
623     </p>
624    
625     <pre caption="Updating the system packages">
626     # <i>emerge --update system</i>
627     </pre>
628    
629     <p>
630     An identical approach can be used for the world packages:
631     </p>
632    
633     <pre caption="Updating your entire system">
634     # <i>emerge --update world</i>
635     </pre>
636    
637     <p>
638     Again, if you want to see what <c>emerge</c> wants to update, use the
639     <c>--pretend</c> option together with the <c>--update</c> option:
640     </p>
641    
642     <pre caption="Pretending to update your entire system">
643     # <i>emerge --pretend --update world</i>
644     <comment>(Some output removed to improve readability)</comment>
645     [ebuild U ] net-misc/wget-1.9-r1 [1.9]
646     [ebuild UD] media-video/dvdauthor-0.5.0 [0.5.3]
647     [ebuild U ] net-analyzer/ethereal-0.9.16 [0.9.14]
648     </pre>
649    
650     <p>
651     Right next to the word "ebuild" you will notice a letter (or combination of
652     letters) which gives you more information about the package:
653     </p>
654    
655     <ul>
656     <li>
657     <e>B</e> (blocks) The package listed to the left is blocking the emerge of
658     the package listed to the right
659     </li>
660     <li>
661     <e>N</e> (new) The package is new to your system and will be emerged for the
662     first time
663     </li>
664     <li>
665 swift 1.32 <e>R</e> (replace) The package isn't new, but will be reemerged
666 swift 1.3 </li>
667     <li>
668 swift 1.15 <e>F</e> (fetch) The package requires that you download the source code
669 swift 1.3 manually (for instance due to licencing issues)
670     </li>
671     <li>
672     <e>U</e> (update) The package already exists on your system but will be
673     upgraded
674     </li>
675     <li>
676     <e>UD</e> (downgrade) The package already exists on your system but will be
677     downgraded
678     </li>
679     </ul>
680    
681     <p>
682 swift 1.25 We have mentioned that the <e>world</e> file doesn't contain dependencies. When
683     you run <c>emerge --update world</c> only the packages mentioned in the
684     <e>world</e> file and it's immediate dependencies are checked and, if necessary,
685     upgraded. If you want <c>emerge</c> to check <e>all</e> the dependencies
686     (including the dependencies of the dependencies), add the <c>--deep</c> flag:
687     </p>
688    
689     <pre caption="Upgrading your entire system, including all dependencies">
690     # <i>emerge --update --deep world</i>
691     </pre>
692    
693     <p>
694 swift 1.4 Of course, we are talking here about <e>system</e> and <e>world</e>, but you can
695 swift 1.3 perform the same actions for individual software packages.
696     </p>
697    
698 swift 1.1 </body>
699     </subsection>
700     <subsection>
701     <title>Removing Software</title>
702     <body>
703    
704 swift 1.3 <p>
705     If you want to remove software from your system, you can use the <c>unmerge</c>
706     option (<c>-C</c> - capital C - in short):
707     </p>
708    
709     <pre caption="Uninstalling software">
710     # <i>emerge unmerge gnumeric</i>
711     </pre>
712    
713     <p>
714     If you want to test a removal (but not perform it), you can use <c>--pretend</c>
715     again:
716     </p>
717    
718     <pre caption="Pretending to uninstall software">
719     # <i>emerge --pretend unmerge gnumeric</i>
720     </pre>
721    
722     <warn>
723     Portage doesn't verify if a package is a dependency for another
724     installed package. It also doesn't warn you if the package is part of
725     <e>system</e>, i.e. a core application necessary for the correct functioning of
726     your system!
727     </warn>
728 swift 1.11
729     <p>
730     Once the unmerge begins you will see a long list of filenames belonging to the
731     package. Some of these filenames will have a flag displayed to the
732     left of the filename. The flags <c>!mtime</c>, <c>!empty</c>, and <c>cfgpro</c>
733     specify reasons why certain files are not being removed while the package is.
734     Files listed without any of these three flags are removed from the
735     filesystem successfully. The three flags specify the following reasons:
736     </p>
737    
738     <ul>
739     <li>
740     <c>!mtime</c> : The listed file has been changed since it was installed,
741     probably by you or some tool
742     </li>
743     <li>
744     <c>!empty</c> : The listed directory is not empty
745     </li>
746     <li>
747 swift 1.16 <c>cfgpro</c> : This file is located inside a protected directory and will
748     not be touched for safety
749 swift 1.11 </li>
750     </ul>
751 swift 1.3
752 swift 1.1 </body>
753     </subsection>
754     </section>
755     <section>
756 swift 1.30 <title>Working with Masked Packages</title>
757 swift 1.1 <subsection>
758     <title>ARCH or not?</title>
759     <body>
760    
761 swift 1.3 <p>
762     Gentoo places its packages in two possible stadia called <e>ARCH</e> and
763     <e>~ARCH</e>. Don't take this literally: the stadia depend on the architecture
764     you are using. In other words, for x86-based systems you have <e>x86</e> and
765     <e>~x86</e>, for ppc-based systems you have <e>ppc</e> and <e>~ppc</e> etc.
766     </p>
767    
768     <p>
769     The <e>~ARCH</e> stadium means that the package works for the developer in
770     charge of the package, but that the package hasn't been tested thoroughly enough
771     by the community to be placed in <e>ARCH</e>. <e>~ARCH</e> packages usually go
772     to <e>ARCH</e> after being bugfree for a sufficient amount of time.
773     </p>
774    
775     <p>
776     Your system will use <e>ARCH</e> packages per default. If you want to live on
777 swift 1.21 the edge, don't mind having a broken package once in a while, know how to deal
778     with a broken system and you like submitting bugreports to <uri
779 swift 1.3 link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, then you can opt to use
780     <e>~ARCH</e> packages. To "move" your system to a <e>~ARCH</e>-using system,
781     edit the <c>ACCEPT_KEYWORDS</c> variable in <path>/etc/make.conf</path> so that
782     it reads <e>~ARCH</e> (again: for x86-based systems: <e>~x86</e>, etc.).
783     </p>
784    
785     <p>
786 swift 1.21 Note though that it is far from trivial (if even impossible) to go back to
787     <e>ARCH</e> from <e>~ARCH</e>.
788     </p>
789    
790     <p>
791 swift 1.3 If you want to update your system now, you will notice that <e>a lot</e> of
792     packages will be updated!
793     </p>
794    
795 swift 1.1 </body>
796     </subsection>
797     <subsection>
798     <title>Masked Packages</title>
799     <body>
800    
801 swift 1.3 <p>
802     When you want to install a package, you might come across the following message:
803     </p>
804    
805     <pre caption="Message about masked packages">
806     Calculating dependencies
807     !!! <comment>all ebuilds that could satisfy </comment>&lt;your package&gt;<comment> have been masked.</comment>
808     </pre>
809    
810     <p>
811 swift 1.32 A package can be masked due to several reasons:
812 swift 1.3 </p>
813    
814     <ol>
815     <li>The package is in <e>~ARCH</e> while you use <e>ARCH</e></li>
816     <li>The package is hard-masked explicitly</li>
817 swift 1.32 <li>The package isn't available for your ARCH entirely</li>
818     <li>The package is masked by your profile</li>
819 swift 1.3 </ol>
820    
821     <p>
822 neysx 1.27 If the package is masked because of the first reason, and you <e>really</e>
823     want to install it (knowing that there <e>is</e> a reason why it isn't
824     available in <e>ARCH</e>), you can accept the <e>~ARCH</e> version of any
825     package by adding it to your <path>/etc/portage/package.keywords</path> file:
826 swift 1.3 </p>
827    
828 neysx 1.27 <pre caption="Accepting the ~ARCH version of a package">
829 swift 1.29 <comment>(Create the /etc/portage directory if it doesn't exist yet)</comment>
830     # <i>mkdir /etc/portage</i>
831    
832 neysx 1.27 # <i>echo "app-office/gnumeric ~x86" &gt;&gt; /etc/portage/package.keywords</i>
833     # <i>emerge gnumeric</i>
834 swift 1.3 </pre>
835    
836     <p>
837     A package is hardmasked if it is listed in
838     <path>/usr/portage/profiles/package.mask</path>. If you read this file, you
839     will also read the reason why the package is hardmasked (it is usually added as
840     a comment). If you want to install the package nevertheless (despite all the
841     possible warnings we could ever throw at your head about "breaking your system",
842     "breaks other packages", or "badly needs testing"), create the
843     <path>/etc/portage/package.unmask</path> file and list the package in it (use
844     the same format as is used in <path>/usr/portage/profiles/package.mask</path>).
845     </p>
846    
847 swift 1.29 <pre caption="Unmasking a hard-masked application">
848     <comment>(Create the /etc/portage directory if it doesn't exist yet)</comment>
849     # <i>mkdir /etc/portage</i>
850    
851     # <i>echo "=app-office/gnumeric-1.2.12" &gt;&gt; /etc/portage/package.unmask</i>
852     </pre>
853    
854 swift 1.3 <p>
855     Do <e>not</e> alter the <path>/usr/portage/profiles/package.mask</path> file as
856 swift 1.29 all changes are undone the next time you update your Portage tree.
857     </p>
858    
859     <p>
860     Sometimes you might want to hardmask a (collection of) package(s). This is the
861     case when newer versions of an application don't support something you require
862     or when these versions break something else in your environment.
863 swift 1.3 </p>
864    
865     <p>
866 swift 1.29 To hard-mask a package, create <path>/etc/portage/package.mask</path> and list the
867     package in it (use the same format as mentioned above).
868 swift 1.3 </p>
869    
870 swift 1.29 <pre caption="Hard-masking a package">
871     <comment>(Create the /etc/portage directory if it doesn't exist yet)</comment>
872     # <i>mkdir /etc/portage</i>
873    
874     # <i>echo "&gt;app-office/gnumeric-1.2.10" &gt;&gt; /etc/portage/package.mask</i>
875 swift 1.3 </pre>
876    
877 swift 1.1 </body>
878     </subsection>
879     <subsection>
880     <title>Blocked Packages</title>
881     <body>
882 swift 1.3
883     <p>
884     You have a situation when you receive the following error on your screen:
885     </p>
886    
887     <pre caption="Blocking package">
888     [blocks B ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0)
889     </pre>
890    
891     <p>
892     In the above example, the package <c>bonobo-activation</c> is blocking the
893     emerge of <c>libbonobo</c>. To resolve this issue, remove the
894     <c>bonobo-activation</c> package and continue:
895     </p>
896    
897     <pre caption="Resolving a blocking situation">
898     # <i>emerge unmerge bonobo-activation</i>
899     </pre>
900 swift 1.1
901     </body>
902     </subsection>
903     </section>
904     </sections>

  ViewVC Help
Powered by ViewVC 1.1.20