germinate 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.
Seeds
The contents of the Ubuntu distribution, and others, are managed by means of seeds. 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 build-dependencies.
Seed lists are typically divided up by category: a base or minimal seed might list the core set of
packages required to make the system run at all, while a desktop seed might list the set of packages
installed as part of a default desktop installation. germinate takes these seeds, adds their dependency
trees, and produces an output for each 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
desktop seed will typically inherit from a minimal seed. germinate understands these inheritance
relationships. If a package in the desktop seed depends on ‘foo’, but ‘foo’ is already part of the
minimal seed or dependency list, then ‘foo’ will not be added to the desktop output.
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 list alternatives to the seeded package to allow metapackages to list them, and
users to use those alternatives without having to remove the metapackages.
[...] Seed entries may be followed with ‘ [arch1arch2...]’ 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.
snap:name
Seed entries beginning with ‘snap:’ are snap packages. These are different from deb packages in
that they do not have (build-)dependencies, cannot be recommended, and do not end up in any
resulting metapackages. (If you try to recommend a snap package, it will be ignored completely.)
Snaps specified in seeds will be output in a .snaps file named after the corresponding seed, as
software processing the output of germinate will typically need to treat snaps differently from
debs. germinate will not check remotely to see if a given snap is available, therefore seeds are
expected to explicitly list all architectures a snap is to be seeded on. ‘snap:’ entries can
also be suffixed with "/classic" to indicate that the snaps need to be installed with classic
confinement on end-user systems.
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 .desc files.
germinate-update-metapackage(1) uses some of these headers to reduce the need for fragile
configuration; see its documentation for further details.
A STRUCTURE 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. Features may also be set on a per-seed basis using lines beginning with
‘ * Feature:’ in the seed file.
The following flags are currently defined:
follow-build-depends
Follow Build-Depends fields. This flag is only recognised in individual seed files, not in
STRUCTURE.
follow-build-depends-all
Follow Build-Depends fields for Architecture: all packages. This has no effect if
no-follow-build-depends is set.
follow-recommends
Treat Recommends fields as if they were Depends.
no-follow-build-depends
Do not follow Build-Depends fields.
no-follow-build-depends-all
Do not follow Build-Depends fields for Architecture: all packages, even though Build-Depends are
followed for other packages.
no-follow-recommends
Do not treat Recommends fields as if they were Depends. This flag is only recognised in
individual seed files, not in STRUCTURE.
Build-dependenciesand ‘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.
germinate 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
STRUCTURE file, conventionally called supported.
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.
Outputs
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 README file for full details on
these.
Install Now
PNG Icons
Emojis
