1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
|
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/Attic/portage-user.xml,v 1.15 2003/11/15 00:35:19 neysx Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/portage-user.xml">
<title>Portage User Guide</title>
<author title="Chief Architect"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
<author title="Editor"><mail link="thomasfl@gentoo.org">Thomas Flavel</mail></author>
<author title="Editor"><!-- zhen@gentoo.org -->
John P. Davis
</author>
<author title="Editor"><mail link="carl@gentoo.org">Carl Anderson</mail></author>
<author title="Editor"><mail link="peesh@gentoo.org">Jorge Paulo</mail></author>
<author title="Editor"><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
<abstract>This guide briefly covers how to keep your packages up to date, and how to maintain
your system.</abstract>
<version>1.4</version>
<date>October 9, 2003</date>
<license/>
<chapter>
<title>Getting Started</title>
<section>
<title>Getting Portage Current</title>
<body>
<p>After you get Gentoo Linux installed and you play around a bit, you may find some bugs or
quirks in some packages, or maybe you'd like to install the latest Gentoo Linux software
packages or update your current packages. To do this, you'll need to download our Portage
tree. We have provided several anonymous rsync servers that you can use to get our latest
Portage tree. Here's how you use it.</p>
<p>Use the following command to synchronize your Portage
tree:
</p>
<pre caption = "Getting portage up to date">
# <c>emerge sync</c>
</pre>
<p>Please note that <c>emerge sync</c> automatically evokes
the <i>--clean</i> option, which will delete any of your
personal changes or additions to the <path>/usr/portage tree</path> If you wish to keep your
own ebuilds separate from the main Portage tree, please use the <i>PORTDIR_OVERLAY</i> function.
</p>
<pre caption = "Using PORTDIR_OVERLAY">
<comment>Add this line to <path>/etc/make.conf</path></comment>
PORTDIR_OVERLAY="/dir/where/your/ebuilds/are"
</pre>
<p>If you begin modifying many ebuilds, fixing bugs, etc, you might want to consider
becoming a part of the Gentoo Linux Development Team. Please contact
either <mail link = "drobbins@gentoo.org">Daniel Robbins</mail> or
<mail link = "seemant@gentoo.org">Seemant Kulleen</mail> for more information.
</p>
</body>
</section>
<section>
<title>Updating Portage</title>
<body>
<p>Before using our Portage tree, it's important that you update Portage by doing the
following:
</p>
<pre caption = "Updating Portage">
<comment>This will show you what packages are going to be updated</comment>
# <c>emerge -up system </c>
<comment>This will update the necessary packages</comment>
# <c>emerge -u system </c>
</pre>
<p>Now you'll be using the most recent version of portage, and you can start to use our ebuild
system to update your installed software.</p>
</body>
</section>
</chapter>
<chapter>
<title>Introducing <c>emerge</c></title>
<section>
<title><c>emerge --pretend</c></title>
<body>
<p>Before installing a package, it is a good idea to see what dependencies are going
to be installed, what packages need to be updated, etc. <c>emerge --pretend</c> or
<c>emerge -p</c> can do this for you.
</p>
<pre caption = "Using emerge -p">
# <c>emerge -p xchat</c>
These are the packages that I would emerge, in order.
Calculating dependencies......... done!
[ebuild U] sys-libs/zlib-1.1.3-r2 to /
[ebuild U] dev-libs/glib-1.2.10 to /
[ebuild N ] media-libs/jpeg-6b-r2 to /
[ebuild N ] x11-base/xfree-4.0.3-r3 to /
[ebuild N ] x11-libs/gtk+-1.2.10-r1 to /
[ebuild N ] media-libs/giflib-4.1.0-r3 to /
[ebuild N ] media-libs/tiff-3.5.6_beta to /
[ebuild N ] media-libs/imlib-1.9.10 to /
[ebuild N ] net-irc/xchat-1.4.3 to /
</pre>
<p>In this particular case, we are attempting to emerge <i>xchat</i> on a
machine that does not have X installed. Thus, <c>emerge --pretend</c>
correctly identifies that several dependencies need to be satisfied first.
Specifically, <path>sys-libs/zlib</path> and <path>dev-libs/glib</path> need to
be updated and then a bunch of ebuilds (including <path>x11-base/xfree</path>,
of course) need to be emerged.</p>
</body>
</section>
<section>
<title>USE and <c>emerge</c></title>
<body>
<p>Above, I executed <c>emerge --pretend</c> on a system that did not have
<c>gnome</c> defined in the <c>USE</c> variable in <path>/etc/make.conf</path>.
This means that optional GNOME support, if present, will not be enabled.
However, <path>xchat</path> <e>does</e> have optional GNOME support, so let's
take a look at the <c>emerge --pretend</c> output after I add <c>gnome</c> to
the <c>USE</c> environment variable in <path>/etc/make.conf</path>:
</p>
<pre caption = "Using emerge with USE variables">
# <c>emerge -p xchat</c>
These are the packages that I would emerge, in order.
Calculating dependencies............................ done!
[ebuild N ] media-libs/jpeg-6b-r2 to /
[ebuild N ] gnome-base/libghttp-1.0.9 to /
[ebuild N ] media-libs/audiofile-0.2.1 to /
[ebuild N ] media-sound/esound-0.2.22-r2 to /
[ebuild N ] gnome-base/gnome-env-1.0 to /
[ebuild N ] gnome-base/libxml-1.8.11 to /
[ebuild N ] gnome-base/ORBit-0.5.8 to /
[ebuild N ] gnome-base/oaf-0.6.5 to /
[ebuild U] dev-libs/glib-1.2.10 to /
[ebuild N ] net-libs/libwww-5.3.2-r1 to /
[ebuild N ] media-libs/giflib-4.1.0-r3 to /
[ebuild N ] dev-util/guile-1.4-r3 to /
[ebuild U] sys-libs/zlib-1.1.3-r2 to /
[ebuild N ] x11-base/xfree-4.0.3-r3 to /
[ebuild N ] x11-libs/gtk+-1.2.10-r1 to /
[ebuild N ] media-libs/tiff-3.5.6_beta to /
[ebuild N ] media-libs/imlib-1.9.10 to /
[ebuild N ] gnome-base/gnome-libs-1.2.13 to /
[ebuild N ] gnome-base/glibwww-0.2-r1 to /
[ebuild N ] gnome-base/gdk-pixbuf-0.11.0 to /
[ebuild N ] gnome-base/gconf-1.0.0 to /
[ebuild N ] gnome-base/gnome-vfs-1.0.1 to /
[ebuild N ] gnome-base/control-center-1.4.0.1 to /
[ebuild N ] gnome-base/scrollkeeper-0.2 to /
[ebuild N ] dev-util/xml-i18n-tools-0.8.1 to /
[ebuild N ] gnome-base/libglade-0.16-r1 to /
[ebuild N ] gnome-base/gnome-core-1.4.0.4 to /
[ebuild N ] net-irc/xchat-1.4.3 to /
</pre>
<p>As you can see, with <c>gnome</c> added to <c>USE</c>, emerge recognizes
that xchat should include optional GNOME support. Of course that in order for
this optional GNOME support to compile and run correctly, GNOME must first be
installed. <c>emerge</c> figures this all out and adds various packages
required by GNOME to its list of ebuilds to emerge. There may be times where
your <c>USE</c> variable is not set correctly, causing <c>emerge</c> to
unexpectedly include or exclude support for various optional extensions.
That's why I recommended that you always perform an <c>emerge --pretend</c>
before executing the actual <c>emerge</c>, especially for new, unfamiliar
ebuilds. That way, you'll know what to expect. :) Once everything looks OK,
you can go ahead with the actual <c>emerge</c> by dropping the <c>--pretend</c>
option:</p>
<pre caption = "Emerging xchat">
# <c>emerge xchat</c>
</pre>
<p>After all dependencies are emerged (if they exist; not all packages have
them), the xchat sources will be downloaded (to
<path>/usr/portage/distfiles</path>), verified, unpacked, compiled and
installed to a temporary directory called the sandbox. Then, they will be emerged into the local
filesystem and a package database will be created at
<path>/var/db/pkg/net-irc/xchat-1.4.3/CONTENTS</path>, containing the files
installed and the md5sums for all files.</p>
<p>
If you want to see what USE-flags you can use with a certain package, and
which ones are triggered on your system, add the <c>-v</c> or
<c>--verbose</c> argument to <c>emerge -p</c>:
</p>
<pre caption = "Using emerge with --verbose">
# <i>emerge -pv gentoo-sources</i>
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild U ] sys-kernel/gentoo-sources-2.4.20-r5 -build +crypt -evms2
-aavm -usagi
</pre>
</body>
</section>
<section>
<title>Finding out what has changed</title>
<body>
<p>
If you want to find out what has changed between the package-version you
have installed, and the one available from Portage, add the
<c>--changelog</c> or <c>-l</c> argument:
</p>
<pre caption = "Viewing the ChangeLog">
# <i>emerge -pl mozilla</i>
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild U ] net-www/mozilla-1.3-r1 [1.2.1-r5]
*mozilla-1.3-r1
22 Mar 2003; Martin Schlemmer <azarah@gentoo.org> mozilla-1.3-r1.ebuild :
Add Gtk2 patch. Add default/prefs/xft.js when Xft is enabled. Some other
long overdue cleanups.
*mozilla-1.3
21 Mar 2003; Jay Kwak <jayskwak@gentoo.org> mozilla-1.3.ebuild :
Add XIM input patch for GTK
18 Mar 2003; Martin Schlemmer <azarah@gentoo.org> mozilla-1.3.ebuild :
New version.
13 Mar 2003; Olivier Reisch <doctomoe@gentoo.org> mozilla-1.2.1-r5.ebuild :
Marked ppc stable
*mozilla-1.3_beta
23 Feb 2003; Martin Schlemmer <azarah@gentoo.org> mozilla-1.3_beta.ebuild :
New version.
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Upgrading packages</title>
<section>
<body>
<p>The standard way to update a package in Portage is to use <c>emerge --update</c>
or <c>emerge -u</c>.
</p>
<pre caption = "Using emerge -u">
# <c>emerge -u xchat</c>
</pre>
<p>
Portage uses what is called a "safe" unmerge; it's only going to
unlink original files. If a file has been overwritten or modified in some way,
it will be left on the filesystem (presumably, you've installed a newer version
of the package). So, if you unmerge an old version of xchat after emerging a
newer version, the xchat executable will not be deleted off your filesystem,
since it has a newer timestamp and different md5sum. Safe unmerges are really
great because they ensure that some version of the application is available at
all times. If you had to unmerge first, then xchat wouldn't be available
for a few minutes while the new version was being downloaded, compiled,
installed and emerged.</p>
<impo>Portage now has a special feature called "config file protection". The
purpose of this feature is to prevent new package installs from clobbering
existing configuration files. By default, config file protection is turned on
for /etc and the KDE configuration dirs; more may be added in the future. Type
<c>emerge --help config</c> for more details.</impo>
</body>
</section>
</chapter>
<chapter>
<title>Resolving Blocked Packages</title>
<section>
<body>
<p>
Currently installed packages can sometimes block the installation of
other packages. This can happen when the functionality of one package
has moved to another package or when two packages are incompatible.
A blocking package must be removed from the system before the blocked
package can be emerged.
</p>
<pre caption = "Emerging a package that is blocked">
# <i>emerge -pv libbonobo</i>
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[blocks B ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0)
[ebuild U ] gnome-base/ORBit2-2.8.1 [2.6.3] -doc +ssl
[ebuild U ] gnome-base/libbonobo-2.4.0 [2.2.3] -doc
</pre>
<p>
In the above example the package bonobo-activation is blocking the installation of
libbonobo-2.4.0.
</p>
<pre caption = "Removing a blocking package from the system">
# <i>emerge -C bonobo-activation</i>
# <i>emerge libbonobo</i>
</pre>
<p>
Removing bonobo-activation from the system will allow
libbonobo-2.4.0 to emerge succesfully.
</p>
<impo>
Performing an unmerge (<c>emerge -C</c>) will remove a package even if
it is a dependancy for other packages, possibly breaking the system.
</impo>
</body>
</section>
</chapter>
<chapter>
<title>Controlling Portage's Behaviour</title>
<section>
<body>
<p>
If you want to change Portage's behaviour, you should edit
<path>/etc/make.conf</path>. It contains variables (or example values
for variables) which you can define to alter Portage's conduct.
For instance, if you want to change how Portage downloads sourcecode,
you should alter <c>FETCHCOMMAND</c> to your own needs.
</p>
<p>
<path>/etc/make.conf</path> contains lots of example variable
settings from which you should be able to derive how to define them.
You should also take a look at the <path>make.conf</path> manpage
(<c>man make.conf</c>) and, if you want to dive deeper into the world
of Portage, read the <uri link="/doc/en/portage-manual.xml">Portage
Manual</uri>.
</p>
<p>
If you need to change a variable for only one run, then you can set it
as an environment variable instead of editing <path>/etc/make.conf</path>
twice. For instance <c>AUTOCLEAN="no" emerge kde</c> will disable
autocleaning during <c>emerge kde</c> only.
</p>
</body>
</section>
</chapter>
<chapter>
<title>What are masked packages?</title>
<section>
<body>
<p>
Many people are curious as to why a newly released package isn't included
when they run <c>emerge -u world</c>. A good example of this is xfree-4.3.0
(the version at the time of this writing). If you've run <c>emerge sync</c>
followed by <c>emerge -u world</c>, you won't see xfree as an update
candidate. Why is this?
</p>
<p>
The reason is that certain packages are marked as "masked"--that is, the
package will not be automatically upgraded or installed unless you take
specific actions to do so. For an explanation of how to enable installation
of masked packages, we encourage you to visit the <uri
link="http://forums.gentoo.org/viewtopic.php?t=33534">Masked Packages
FAQ</uri> in our <uri link="http://forums.gentoo.org/">Gentoo Forums</uri>.
</p>
</body>
</section>
</chapter>
</guide>
|
GitWeb