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
|
#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true"
<P>
At the heart of the system is the <TT>wanna-build</TT> database, which
keeps track of package versions and states. <TT>quinn-diff</TT>
compares the package lists for the target architecture against the list
of source packages after every archive update and feeds a list of packages
that need re-compilation into the database where they enter state
<TT>Needs-Build</TT>.
<P>
All the build daemons (there can be more than one) query the database
regularly for such packages and take some of them so that they go
into state <TT>Building</TT>. Of course, humans also can take
packages, e.g. in special cases where automatic compilation isn't
possible. Here we also see the second purpose of <TT>wanna-build</TT>:
It ensures that the same version of a package won't be built twice.
<DIV class="center"><A name="autobuilder34"></A>
<IMG SRC="scheme.png" alt="Autobuilder scheme">
<p><STRONG>Figure:</STRONG>
Package States and Transitions</p>
</DIV>
<P>
If everything goes well, a finished package can be uploaded later,
which is another state <TT>Uploaded</TT>. After that it will
eventually be installed into the Debian archive so it appears in the
updated package list for the target architecture. This list will be
merged into the database, so the package will go to state
<TT>Installed</TT> and remains there until the next version of the source package.
<P>
There are several other states; they include: <TT>Failed</TT> is for
packages that failed to build due to errors in the sources, and the
errors are expected to be fixed in a successor version (after
reporting the problem, of course). So a new version will directly
enter <TT>Needs-Build</TT>, but with a warning that something was
wrong with the previous version. Along with this state an error
description is stored. State <TT>Dep-Wait</TT> is used when a package
needs some other packages to be compiled but those aren't available
yet and must be built before. This state stores a list of required
packages and maybe versions, and if all of them are known to be
installed the state changes back to <TT>Needs-Build</TT>.
<P>
As we have already seen, the build daemon takes packages from the
database for compiling them. Let's look a bit closer: If it has some
packages to build, it uses <TT>sbuild</TT> for the actual compilation
process, and for each build a log is mailed to the maintainer of the
daemon. He reviews the log and decides what to do with the package:
upload it, set it to <TT>Failed</TT> or <TT>Dep-Wait</TT> and retry it,
etc... If a positive acknowledgement (a signed <TT>.changes</TT>
file) is received, the daemon moves it to an upload directory, from where
all packages are uploaded by a cron job.
<P>
Looking at the log files is the only human intervention in the whole
process if no errors happen. There are two good reasons for not
further automating this: First, sometimes builds end with an ``OK''
result but the build nevertheless failed for reasons that are
invisible to the machine. And second, directly uploading would require
to automatically PGP-sign the resulting files with a key without
passphrase on the build machine. I considered this an unacceptable
security hole.
<P>
The build script <TT>sbuild</TT> more or less just calls some standard
Debian tools to compile the sources. It also helps with some common
tasks and bookkeeping and with automatically installing the
build-dependencies as requested by the package being built.
<hrline />
<p><small>Content developed by Roman Hodek for the
6th International Linux-Kongress 1999; it was gently updated to reflect
the current reality a bit more by Philipp Kern in 2009</small></p>
|
