NAME

     germinate — expand dependencies in a list of seed packages

SYNOPSIS

     germinate [-v] [-S source] [-s dist] [-m mirror] [-d dist,...] [-a arch] [-c component,...]
               [--vcs={auto|bzr|git}] [--no-rdepends] [--no-installer]

DESCRIPTION

     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 ‘ [arch1 arch2 ...]’ 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-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.

     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.

OPTIONS

     -v, --verbose
           Be more verbose when processing seeds.

     -S, --seed-source source,...
           Fetch seeds from the specified sources.  The default is
           https://ubuntu-archive-team.ubuntu.com/seeds/, or
           http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ if the --vcs=bzr option is
           used, or git://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ 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 stored in /home/username/seeds/debian.unstable,
           then you would use the options -S file:///home/username/seeds/ -s debian.unstable.

     -s, --seed-dist dist
           Fetch seeds for distribution dist.  The default is ubuntu.mantic.

           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.

     -m, --mirror mirror
           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.

     --source-mirror mirror
           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.

     -d, --dist dist,...
           Operate on the specified distributions.  The default is mantic.  Listing multiple
           distributions may be useful, for example, when examining both a released distribution
           and its security updates.

     -a, --arch arch
           Operate on architecture arch.  The default is amd64.

     -c, --components component,...
           Operate on the specified components.  The default is main.

     --vcs={auto|bzr|git}
           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 seed-source/seed-dist; for git, remove the part after the rightmost ‘.’
           character of seed-dist and use it as the branch name to check out from
           seed-source/remainder-of-seed-dist.  For auto, guess the version control system to use
           from seed-source (trying both in ambiguous cases) and then proceed as above.

     --bzr
           Check out seeds from the bzr branch found at seed-source/seed-dist rather than
           fetching them directly from a URL.  Requires bzr to be installed.  This option is
           deprecated and is retained for backward compatibility; use --vcs=bzr instead.

     --no-rdepends
           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 time.

     --no-installer
           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 system.

     --seed-packages parent/pkg,...
           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, --seed-packages desktop/epiphany-browser
           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 epiphany-browser.

     --always-follow-build-depends
           Always follow Build-Depends in all seeds, regardless of seed feature flags.

BUGS

     The wiki-style markup in seeds was inherited from an early implementation, and is a wart.

     germinate 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.

AUTHORS

     Scott James Remnant <scott@canonical.com>
     Colin Watson <cjwatson@canonical.com>

     germinate 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 /usr/share/common-licenses/GPL.