# Glossary Plain-language definitions of package, snapshot, and verification terms used in these docs. Source: https://debark.dev/docs/reference/glossary --- Use this page when you encounter an unfamiliar term. You do not need to learn these terms before following the [quick start](/docs/get-started/quickstart). ## Terms ### air gap A separation that prevents a machine or network from reaching another network, often the internet. Debark also works with machines that are temporarily offline. ### apt The Debian and Ubuntu package manager that selects package versions and dependencies. Debark uses apt to plan bundles and install them. ### archive A collection of packages published by a distribution or another provider. Repository sources tell apt which archives to use. ### backend Where package resolution runs: local apt on the builder, or apt inside a container. See [Build backends](/docs/concepts/backends). ### base A stock release used when you cannot capture the target, such as `ubuntu:24.04/server`. It assumes an installed package set. ### baseline OS A stock Debian or Ubuntu installation described by its release, variant, and architecture. The CLI calls it a **base** and selects it with `--base`, so no captured snapshot is required. See [Build with a baseline OS](/docs/get-started/no-target-machine). ### base definition A file describing a base’s release, initial packages, and recommendation settings. `snapshot list-bases` lists the built-in definitions. ### bundle The folder or compressed archive produced by a build. It contains package files, an install plan, and verification metadata. See [Bundle format](/docs/reference/bundle-format). ### canonical JSON A consistent JSON representation used when calculating document checksums and signatures. It prevents formatting differences, such as indentation, from changing the signed representation. ### captured snapshot A snapshot created from an actual machine with `debark snapshot create`. It records that machine’s package state at the time of capture. ### closed-world check An offline dependency check against the finished bundle. The result is recorded as `ok`, `failed`, or `skipped` in the lock. It does not run every package’s installation scripts. ### closure (dependency closure) The requested packages and all the packages they depend on, including dependencies of dependencies. See [Package dependencies](/docs/concepts/closure). ### content-addressed store Debark’s download cache. Files are identified by their content checksums so matching downloads can be reused. See [Download cache and cleanup](/docs/concepts/store-and-incremental). ### `.deb` A Debian-format package file containing software, package metadata, and sometimes installation scripts. ### deb822 A field-based text format used by Debian tools, including apt’s `.sources` files. Entries have names such as `Types`, `URIs`, and `Suites`. ### dependency A package another package needs to work. apt selects versions that meet the declared requirements. ### detached signature A signature stored in a separate file from the document it signs. A signed bundle keeps its signature in `debark.manifest.sig`. ### dpkg The tool that unpacks and configures Debian packages and records their installed state. apt uses it to apply an installation plan. ### dpkg status file The database of package installation states, normally at `/var/lib/dpkg/status`. A snapshot captures it to show what the target already has. ### evidence record The build events saved in `evidence.json`. See [SBOM and build records](/docs/trust/sbom-and-evidence). ### flat repository An apt repository with `Packages` and `Release` files directly at its root. The bundle’s `repo/` directory uses this layout. ### foreign architecture An additional package architecture enabled on a machine, such as `i386` on an `amd64` target. ### held package A package marked to stay at its current version. Holds can prevent upgrades or create conflicts with a new package request. ### keyring A collection of keys. Debark’s `--keyring` takes a directory of public key files; `--gpg-keyring` takes a GPG keyring file. ### lock file The `lock.json` document recording selected versions, package sources, and the install set. See [Package versions and the lock file](/docs/concepts/lockfile). ### maintainer script A script included in a `.deb` that runs during package installation, configuration, or removal. It may need resources beyond the package’s apt dependencies. ### manifest The `debark.manifest.json` document that lists bundle files and their checksums. A bundle signature covers this document. ### multiarch Debian’s support for packages from more than one architecture on the same machine. A package may need an architecture-qualified name to distinguish it. ### phased update An update offered gradually to eligible machines. Snapshot machine-ID handling can affect this selection. See [Phased updates](/docs/concepts/snapshots#phased-updates). ### pin An apt preference that changes which package version or source is selected. A `name=version` request also selects an exact version for that request. ### pool The bundle’s `repo/pool/` directory, where the `.deb` files are stored. ### private apt root A temporary set of apt settings and package state used for a build or install. It lets Debark use the required sources without replacing the machine’s normal apt configuration. ### provenance Information about where a package came from and how its source was checked. In the docs, this is usually called package source information. ### `publisher_verification` A lock-file field describing how a package’s publisher or expected contents were checked. See [How verification works](/docs/trust/trust-model). ### Recommends Optional package relationships that apt commonly includes by default. Debark follows the target’s setting unless you use `--recommends` or `--no-recommends`. ### Release file Repository metadata containing checksums of apt indexes. A normal archive signs its release metadata; Debark checks its bundled repository through the bundle manifest. ### reproducible build A build that can produce identical output when all relevant inputs are fixed. See [Repeatable builds](/docs/concepts/reproducibility) for the inputs that matter. ### SBOM Software bill of materials: a package inventory in a standard format. `build --sbom` adds a CycloneDX JSON file to the bundle. ### sha256 digest A SHA-256 checksum calculated from file contents. A changed checksum indicates changed bytes; a checksum alone does not identify the publisher. ### `Signed-By` An apt source setting that limits which keys can authenticate that repository’s metadata. ### snap shim A small `.deb` that directs installation to Snap instead of carrying the full application. See [Snap packages](/docs/operate/troubleshooting#snap-packages). ### snapshot A portable description of the target’s package state and apt settings. It tells the builder what is installed and which repositories and preferences to use. ### source package The source code and packaging used to produce one or more binary `.deb` packages. Its name can differ from the installed package name. ### suite A repository release or update channel, such as `bookworm` or `noble-updates`. ### synthesized snapshot A snapshot generated from a base definition instead of captured from a machine. Its installed package list is an assumption about a stock system. ### target The Debian or Ubuntu machine where the bundle will be installed. ### unreferenced pool file A `.deb` left in the bundle folder but absent from its current apt index. It uses disk space but is not offered by that index. ### vendor `.deb` A package supplied as a local file or direct download, rather than selected from the target’s apt repositories. See [Include vendor packages](/docs/guides/vendor-debs).