/[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.9 - (hide annotations) (download) (as text)
Sun Nov 30 11:31:38 2003 UTC (10 years, 9 months ago) by swift
Branch: MAIN
Changes since 1.8: +11 -10 lines
File MIME type: application/xml
getbinpkg(only) commented out

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

  ViewVC Help
Powered by ViewVC 1.1.20