xenial (1) germinate.1.gz

Provided by: germinate_2.25_all bug

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

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

     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
           http://people.canonical.com/~ubuntu-archive/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.xenial.

           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 xenial.  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 i386.

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

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.