expand dependencies in a list of seed
is a program to help with the maintenance
of large software distributions. It takes a list of seed packages and a mirror
of the distribution, and produces outputs with the seed packages and their
dependencies and build-dependencies expanded out in full.
The contents of the Ubuntu distribution, and others, are managed by means of
. At their simplest, these are lists of
packages which are considered important to have in the main component of the
distribution, without explicitly listing all their dependencies and
Seed lists are typically divided up by category: a
seed might list the core set of packages
required to make the system run at all, while a
seed might list the set of packages installed
as part of a default desktop installation.
takes these seeds, adds their
dependency trees, and produces an output
seed which contains a dependency-expanded list of package names. These outputs
may be handed on to archive maintenance or CD-building tools.
Some seeds may inherit
from other seeds: they rely
on those seeds to be installed. For example, a
seed will typically inherit from a
understands these inheritance
relationships. If a package in the
depends on ‘foo’, but ‘foo’ is already part of the
seed or dependency list, then
‘foo’ will not be added to the
Seeds are stored in text files downloaded from a given URL. Lines not beginning
with ‘ * ’ (wiki-style list markup) are ignored.
Seed entries may simply consist of a package name, or may include any of the
following special syntax:
- Seed entries beginning with ‘%’ expand to all
binaries from the given source package.
- Seed entries may be followed with ‘
...]’ to indicate that they should only be used on the given
architectures, or with ‘ [!arch1
!arch2 ...]’ to indicate that they
should not be used on the given architectures.
- Seed entries in parentheses indicate that the seed should
be treated as a recommendation of metapackages generated from this seed,
rather than as a dependency.
- Seed entries beginning with ‘!’ cause the
given package to be blacklisted from the given seed and any seeds from
which it inherits; this may be followed by ‘%’ as above to
blacklist all binaries from the given source package. Note that this may
result in uninstallable packages whose dependencies have been blacklisted,
so use this feature sparingly. The purpose of a blacklist is to make it
obvious when a package that is not supposed to be installed ends up in
germinate's output, so that package
relationships can be fixed to stop that happening. It is not intended for
the purpose of working around buggy package relationships, and attempts to
do so will not work because apt has no way to
know about blacklist entries in seeds.
- key: value
- Some seeds also contain headers at the top of the file, in
“key: value” format. For the most part, these are not parsed
by germinate itself. The Ubuntu
tasksel package uses keys beginning with
‘Task-’ to define fields of similar names in its
germinate-update-metapackage(1) uses some of
these headers to reduce the need for fragile configuration; see its
documentation for further details.
file alongside the seeds lists their
inheritance relationships. It may also include lines beginning with
‘include’, causing other collections of seeds to be included as
if they were part of the collection currently being germinated, or lines
beginning with ‘feature’, which set flags for the processing of
seeds. The only flag currently defined is ‘follow-recommends’,
which causes germinate
to treat Recommends fields
as if they were Depends. (Features may also be set on a per-seed basis using
lines beginning with ‘ * Feature:’ in the seed
file; here, ‘no-follow-recommends’ is also supported to allow
Recommends-following to be turned off for individual seeds.)
Build-dependencies and ‘supported’
There is typically no need for a default desktop installation to contain all the
compilers and development libraries needed to build itself from source; if
nothing else, it would consume much more space. Nevertheless, it is normally a
requirement for the maintainers of a distribution to support all the packages
necessary to build that distribution.
therefore does not add all the packages
that result from following build-dependencies of seed packages and of their
dependencies (the “build-dependency tree”) to every output,
unless they are also in the seed or in the dependency list. Instead, it adds
them to the output for the last seed in the
file, conventionally called
Like any other seed, the supported seed may contain its own list of packages. It
is common to provide support for many software packages which are not in the
default installation, such as debugging libraries, optimised kernels,
alternative language support, and the like.
The output files are named after the seed to which they correspond. An
additional output file is needed for supported, namely
‘supported+build-depends’, which contains the supported list and
the build-depends lists of the other seeds all joined together. An
‘all’ output is produced to represent the entire archive.
Some other files are produced for occasional use by experts. See the
file for full details on these.
- Be more verbose when processing seeds.
- Fetch seeds from the specified sources. The default is
if the --vcs=bzr
option is used, or
if the --vcs=git
option is used. You may use file:// URLs here
to fetch seeds from the local file system; for example, if your seeds are
you would use the options -S
- Fetch seeds for distribution
dist. The default is
When fetching seeds from git, the part after the rightmost ‘.’
character, if any, is treated as the branch name to check out; this rather
strange style is for backward compatibility.
- Get package lists from
mirror. The default is
http://archive.ubuntu.com/ubuntu/. May be
supplied multiple times; the newest version of each package across all
archives will win.
- Get source package lists from
mirror. The default is to use package
lists mirrors. May be supplied multiple times; the newest version of each
source package across all archives will win.
- Operate on the specified distributions. The default is
zesty. Listing multiple distributions may be
useful, for example, when examining both a released distribution and its
- Operate on architecture
arch. The default is
- Operate on the specified components. The default is
- Check out seeds from a version control system rather than
fetching them directly from a URL. Requires
bzr or git, as
appropriate, to be installed. For bzr, use
the branch found at
for git, remove the part after the rightmost
‘.’ character of seed-dist
and use it as the branch name to check out from
For auto, guess the version control system to
use from seed-source (trying both in
ambiguous cases) and then proceed as above.
- Check out seeds from the bzr
branch found at
rather than fetching them directly from a URL. Requires
bzr to be installed. This option is
deprecated and is retained for backward compatibility; use
- Disable reverse-dependency calculations. These calculations
cause a large number of small files to be written out in the
rdepends/ directory, and may take some
- Do not consider debian-installer udeb packages. While
generally not the desired outcome, sometimes you might wish to omit
consideration of installer packages when processing your seeds, perhaps if
sending the output directly to the package manager on an already-installed
- Treat each pkg as a seed
by itself, inheriting from parent (i.e.
assuming that all packages in the parent
seed are already installed while calculating the additional dependencies
of pkg). This allows the use of
germinate to calculate the dependencies of
individual extra packages. For example,
will create an epiphany-browser output file
listing the additional packages that need to be installed over and above
the desktop seed in order to install
- Always follow Build-Depends in all seeds, regardless of
seed feature flags.
The wiki-style markup in seeds was inherited from an early implementation, and
is a wart.
can sometimes be confused by complicated
situations involving the order in which it encounters dependencies on virtual
packages. Explicit entries in seeds may be required to work around this.
Handling of installer packages (udebs) is complicated, poorly documented, and
doesn't always work quite right: in particular, packages aren't demoted to the
supported seed when they should be.
Scott James Remnant
is copyright © 2004, 2005, 2006,
2007, 2008 Canonical Ltd
. See the GNU
General Public License version 2 or later for copying conditions. A copy of
the GNU General Public License is available in