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
|
<chapter id="howitworks">
<title>How it works</title>
<para>
In this chapter, we'll try to explain how autoepatch works, and how to
extend it to patch and fix new problems. The reason to provide a
throughout documentation about this is to make the maintainership of
autoepatch simpler, so that if the developers currently involved in
its writing would not be available, newcomers won't have to read all
the code to find how it actually works.
</para>
<sect1 id="concepts">
<title>Concepts</title>
<para>
There aren't many concepts to describe on autoepatch because it is,
basically, a simple set of scripts. The definitions that will be given
here are not even proper "concepts" but this section is intented to
clear up the terminology used, so that there can't be misunderstanding
in the next sections and chapters.
</para>
<variablelist>
<varlistentry>
<term>patchset</term>
<listitem>
<para>
With this term, the documentation will refer to a set of scripts
and actual patches, the base element handled by autoepatch itself.
Despite the name used seem to limit a patchset to just patches,
it's well possible that a patchset has no actual ".patch" file,
and instead consist of a single shell script that describes the
changes to apply to targets.
</para>
<para>
The patchsets can be found in the repository inside the patches
directory, or for the installed copy in
/usr/share/autoepatch/patches
<footnote><para>
For alternative prefixes support, see <xref
linkend="prefixsupport" />.
</para></footnote>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>target</term>
<listitem>
<para>
Under this name we consider a file, or a directory, on which the
patchset applies. When the target is a directory, ad the patchset
contains actual patches, the paths inside the patches should refer
to the direct name of the files starting from the target directory
(-p0 option to gpatch); when the target is a file instead, the
patch will apply directly over the file. When instead the patchset
consist of a function (or a series of functions), the target is
passed as parameter, whichever the type it is.
</para>
<para>
For more informations about target, look at <xref
linkend="writingpatchsets" />.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="prefixsupport">
<title>Alternative prefixes support</title>
<para>
Although Portage, at the time of writing, it's limited to work as a
primary package manager and does not support officially a way to
install packages on an alternate prefix (like /usr/local or something
else), autoepatch is designed to support being installed in an
arbitrary prefix from day one.
</para>
<para>
To install autoepatch on a different prefix, you should just replace
the string <emphasis>@PREFIX@</emphasis> with the prefix the package
is installed in the file autoepatch.sh.
</para>
</sect1>
</chapter>
|
GitWeb