GERMINATE(1)

📦
version 2.50.2+willsync2 · 5 versions
, in ubuntu stonking

💖 GERMINATE(1) — LOCAL manual page, and yes it's giving UNTITLED() energy, we move 💖

okay so bestie, welcome to germinate, the little program that could. This is germinate from section 1 of the local manual — the page itself is literally titled UNTITLED() up top because sometimes manpages just wake up and choose chaos, but we know her name and her name is germinate. 🎀

✨ 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]

look at that little command line. she's compact, she's precise, she's slay. 💅

✨ DESCRIPTION ✨

so like, germinate is a program that helps with the maintenance of large software distributions. That's the whole vibe. You hand her a list of seed packages plus a mirror of the distribution, and she hands you back outputs where the seed packages and their dependencies and their build-dependencies are expanded out in full. no cap, fully expanded. 🔥

🌱 Seeds 🌱

The contents of the Ubuntu distribution (and others, bestie, she's not exclusive) are managed by means of seeds. At their simplest, these are literally just lists of packages that are considered important to have in the main component of the distribution — and the whole point is that you don't have to explicitly list all their dependencies and build-dependencies. iconic lazy-girl behaviour honestly. 👑

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 containing a dependency-expanded list of package names. Those outputs can be handed on to archive maintenance tools or CD-building tools. 🫶

Some seeds may inherit from other seeds: they rely on those seeds being 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. she's not gonna duplicate. she's not gonna embarrass you like that. 🙈

Seeds are stored in text files downloaded from a given URL. Lines not beginning with ‘ * ’ (wiki-style list markup) are ignored. that's the rule. markdown-heading-ass lines, get out. 💀

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. options! variety! main character energy.
  • [...] — 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. architecture gatekeeping, but make it documented. ✨
  • (...) — 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. soft launch, not a hard dep. 🎀
  • ! — Seed entries beginning with ‘!’ cause the given package to be blocklisted from the given seed and any seeds from which it inherits; this may be followed by ‘%’ as above to blocklist all binaries from the given source package. Note that this may result in uninstallable packages whose dependencies have been blocklisted, so use this feature sparingly. The purpose of a blocklist 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 blocklist entries in seeds. 🚨 bestie please read that part again. the blocklist is a snitch, not a fixer.
ngl the ! entry is the one that will humble you if you treat it like a hack. it's a loud alarm, it's a vibe check for your package relationships, it is not a workaround. periodt.
  • 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. big agree, she does not need the entire toolchain in her handbag. Nevertheless, it is normally a requirement for the maintainers of a distribution to support all the packages necessary to build that distribution. that's the actual job, bestie.

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

okay and like, this page keeps going — we're only on part 1 of 2, so don't go anywhere, there's more 💖

✨ OPTIONS ✨

okay bestie, this is the part where the page gets long, but every single one of these matters so we're doing all of them, no skipping 💅

  • -v, --verbose — be more verbose when processing seeds. basically: more words, more insight, more you-know-what's-happening ✨
  • -S, --seed-source source,... — fetch seeds from the sources you name ✨ 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.resolute.

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. (iykyk — it's giving "we do a little trolling" but the troll is legacy 🫠)

  • -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. (main character energy — newest wins, periodt 👑)
  • --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 resolute. 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.
  • -C, --apt-config conf — use apt with APT_CONFIG set to the supplied value to find the package and source indices to operate on. Overrides any values passed for --mirror, --source-mirror, --dist, -or --components. (yes, it really says "-or" 😭)
⚠️ heads up: that -C one is the boss option. it overrides all four of the others, so if you pass both, -C is eating, and your other flags are just standing there 💀
  • --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.
🙈 deprecated era! it still works, it's just very 2005. use --vcs=bzr like the girlies do.
  • --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. (skip it if you're in a hurry bestie ⏩)
  • --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 🐛

ngl, this section is the "confession" part of the page and we respect the honesty 💀

  • The wiki-style markup in seeds was inherited from an early implementation, and is a wart. (their words! "a wart"! iconic self-drag 💅)
  • 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 👑

The legends behind it all:

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

and that's the whole thing bestie, you're officially germinate-literate 🧚✨ this gem is from the Ubuntu corner of the world, dated May 27, 2005, and it lives on the page as GERMINATE(1) — go forth and slay those seeds 💜🌸

📦 where this page comes from