Table of contents

1. Minimal build system
   1. Binary packages
   2. Source packages (excluding those building Arch:all)
   3. Source packages (only those building Arch:all)
2. B-D-transitive essential
   1. Summary
   2. Re-use existing Architecture:all and M-A:foreign
   3. Re-use existing Architecture:all
   4. Bootstrap Architecture:all as well
3. Downloadable lists
   1. Essential coinstallation set
   2. Re-use existing Architecture:all and M-A:foreign
   3. Re-use existing Architecture:all
   4. Bootstrap Architecture:all as well

Minimal build system

Source packages (excluding those building Arch:all)

Source packages (only those building Arch:all)

B-D-transitive essential

All source, respective binary packages that are transitively build-essential (or essential - this is equivalent) under the Depends and Build-Depends relationships using three different dependency traversal methods. The three methods are called Strong, Opt. IS and Closure and are explained in the following three paragraphs, respectively. The used terminology is explained in the wiki.

• Strong: Starting from src:build-essential, find all strong dependencies, retrieve the source packages that build these binary packages and recurse until no more vertices are added to the graph.
• Opt. IS: The name is short for "Optimal Installation Set". Starting from src:build-essential, compute an installation set with a minimal number of binary packages, retrieve the source packages that build these binary packages and recurse until no more vertices are added to the graph. This set is a superset of Strong and thus only the additional packages are shown in the full table. The summary table lists the total number of packages in each set.
• Closure: Starting from src:build-essential, traverse every dependency relationship, retrieve the source packages that build these binary packages and recurse until no more vertices are added to the graph. This set is a superset of Opt. IS and thus only the additional packages are shown in the full table. The summary table lists the total number of packages in each set.

These three traversal methods are each applied to three scenarios. The three scenarios are re-use existing Architecture:all and M-A:foreign, re-use existing Architecture:all and Bootstrap Architecture:all as well

• Re-use existing Architecture:all and M-A:foreign: In this method the dependency graph will not connect binary packages that are either Architecture:all or Multi-Arch:foreign to the source packages they build from. This set is calculated because missing metadata makes it impossible to create a dependency graph for the cross bootstrap phase. As a workaround, a native bootstrap is assumed but, just as during the cross phase, Multi-Arch:foreign binaries are assumed to already exist so that their source packages do not need to be compiled to create them.
• Re-use existing Architecture:all: In this method the dependency graph will not connect binary packages that are Architecture:all to the source packages they build from. This is the situation in a regular native bootstrap of Debian for a new architecture, as existing Architecture:all packages that were already built and are in the archive can just be re-used to satisfy dependencies during a native bootstrap.
• Bootstrap Architecture:all as well: In this method the dependency graph will connect all binary packages to their respective source packages. This represents a bootstrap where even Architecture:all packages are being bootstrapped. This is useful if one wants to ensure that no dependencies come from any other source than the bootstrapped repository, for example for security, trustring trust and paranoia reasons.

Summary

Re-use existing Architecture:all and M-A:foreign

Re-use existing Architecture:all

Bootstrap Architecture:all as well

Re-use existing Architecture:all and M-A:foreign