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
|
<?xml version="1.0"?>
<guide self="ebuild-writing/functions/">
<chapter>
<title>Ebuild Functions</title>
<body>
<p>
When installing packages from source, the function call order is
<c>pkg_pretend</c> (for EAPI=4 and later), <c>pkg_setup</c>,
<c>src_unpack</c>, <c>src_prepare</c>, <c>src_configure</c>, <c>src_compile</c>,
<c>src_test</c> (optional, <c>FEATURES="test"</c>),
<c>src_install</c>, <c>pkg_preinst</c>, <c>pkg_postinst</c>. When installing packages
from a binary, the function call order is <c>pkg_pretend</c>,
<c>pkg_setup</c>, <c>pkg_preinst</c>, <c>pkg_postinst</c>.
As some phases haven't been introduced from the beginning, you can have a look at
<uri link="::ebuild-writing/eapi"/> for an overview, what have been introduced in which EAPI.
</p>
<figure short="How the ebuild functions are processed" link="diagram.png"/>
<p>
The <c>pkg_pretend</c> function is to be used for performing various
early sanity checks, such as ensuring that certain kernel options are
enabled. It is important to keep in mind that <c>pkg_pretend</c> runs
separately from the rest of the phase function sequence. Consequently,
there is no environment saving or propagation to the next
phase. Moreover, ebuild dependencies are not guaranteed to be
satisfied at this phase.
</p>
<p>
The <c>pkg_prerm</c> and <c>pkg_postrm</c> functions are called when uninstalling a
package. The <c>pkg_config</c> function is used for any special package
configuration <d/> it is only run when explicitly requested by the user. The
<c>pkg_nofetch</c> function is used when a <c>RESTRICT="fetch"</c> package needs to
obtain some <c>SRC_URI</c> components.
</p>
<p>
Between the transition from <c>pkg_preinst</c> to <c>pkg_postinst</c>, files are
copied over to the live filesystem from the sandboxed temporary installation
location, and Portage records digests of the files installed.
</p>
<p>
When testing or debugging, you can instruct Portage to execute a specific function
from an ebuild by using the <c>ebuild</c> command, see the <c>ebuild(1)</c> manual
page for further information.
</p>
<p>
Downloading a package's source happens before any of these phases, so
<c>emerge --fetchonly</c> should perform all the network access you
need (unless you're using live ebuilds). Network access outside of
this would not be cached locally (e.g. in <c>${DISTDIR}</c>, see
<uri link="::ebuild-writing/variables#Predefined Read-Only Variables"/>),
which makes it hard to have reproducible builds (see
<uri link="::ebuild-writing/functions/src_unpack/cvs-sources#Disadvantages of CVS Sources"/>).
Avoid network access in any phase by using local files, extending
<c>SRC_URI</c> (see
<uri link="::ebuild-writing/variables#Ebuild-defined Variables"/>), etc.
</p>
</body>
<section>
<title>Contents</title>
<body>
<contentsTree/>
</body>
</section>
</chapter>
<include href="pkg_pretend/"/>
<include href="pkg_nofetch/"/>
<include href="pkg_setup/"/>
<include href="src_unpack/"/>
<include href="src_prepare/"/>
<include href="src_configure/"/>
<include href="src_compile/"/>
<include href="src_test/"/>
<include href="src_install/"/>
<include href="pkg_preinst/"/>
<include href="pkg_postinst/"/>
<include href="pkg_prerm/"/>
<include href="pkg_postrm/"/>
<include href="pkg_config/"/>
<include href="pkg_info/"/>
</guide>
|
GitWeb