/usr/share/doc/botch/wiki/ExamplesGraphs.html is in botch-doc 0.16-2ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 | <p>This page gives an overview over the dependency graphs used by botch. Consider the following dependency situation:</p>
<pre><code>$ cat Sources
Package: a
Version: 1.0
Architecture: any
Build-Depends: binaryB
Package: b
Version: 1.0
Architecture: any
Build-Depends: binaryA
$ cat Packages
Package: binaryA
Version: 1.0
Architecture: amd64
Source: a
Depends: binaryB
Package: binaryB
Version: 1.0
Architecture: amd64
Source: b
</code></pre>
<p>Three different types of package interdependencies are expressed:</p>
<ul>
<li>build dependencies (<code>Build-Depends</code> field in <code>Sources</code>)</li>
<li>binary or runtime dependencies (<code>Depends</code> field in <code>Packages</code>)</li>
<li>builds-from relationship (<code>Source</code> field in <code>Packages</code> or implicitly the same name as the binary package)</li>
</ul>
<p>We can visualize this situation as the following graph:</p>
<p><img src="buildgraph1.png" alt="buildgraph1" title="" /></p>
<p>Source package vertices are displayed as rectangles while binary package vertices are displayed as ellipses. Build dependencies are represented by dashed edges, binary dependencies by dotted edges and builds-from relationships by solid edges.</p>
<p>Binary dependencies (the dependency of <code>binaryA</code> on <code>binaryB</code>) cannot conditionally be broken so we merge the two vertices for <code>binaryA</code> and <code>binaryB</code> into a single vertex to simplify the graph.</p>
<p><img src="buildgraph2.png" alt="buildgraph2" title="" /></p>
<p>The new vertex now contains all vertices that represent an installation set of <code>binaryA</code>. This is why this type of vertex is called installation set vertex. The vertex of <code>binaryB</code> was also turned into an installation set vertex but since <code>binaryB</code> does not depend on any other binary packages it is the only binary package in its installation set.</p>
<p>The next figure shows the final graph which we call "build graph". The information about interdependencies between binary packages within an installation set is removed.</p>
<p><img src="buildgraph3.png" alt="buildgraph3" title="" /></p>
<p>The build graph allows to easily spot the two dependency cycles in this setup. A build graph only has two edge types (build dependency and builds-from dependency) and two vertex types (source vertex and installation set vertex). Since an installation set vertex can represent more than one binary package, it can have more than one outgoing builds-from edge.</p>
<p>A so called source graph reduces the graph even further by removing the installation set vertices but keeping the interdependencies between source vertices intact. Here is the source graph of the build graph above:</p>
<p><img src="srcgraph.png" alt="srcgraph" title="" /></p>
<p>A source graph is required to reason about strong dependencies between source packages.</p>
|