Provided by: germinate_2.38_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.

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

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

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

Ubuntu                                            May 27, 2005                                      GERMINATE(1)