Native Packages & Installers

nFPM is a packager written in Go whose documentation lists the formats deb, rpm, apk, ipk, Arch Linux and MSIX. It is configured with a YAML file and does not need dpkg-deb or rpmbuild. It does not template: environment variables are expanded in many fields, so a CI job can set SEMVER and write version: ${SEMVER}.

Source: nFPM — Configuration and nfpm package. The package command takes -f/--config (default nfpm.yaml), -p/--packager and -t/--target (a file name, a folder, or empty for the current folder).

Package signing is configured per format with deb: signature: or rpm: signature: blocks holding key_file and key_id. The passphrase is read from NFPM_DEB_PASSPHRASE or NFPM_RPM_PASSPHRASE, falling back to NFPM_PASSPHRASE; keep these in CI secrets, never in the file. nFPM documents debsign as the default Debian signing method and warns that dpkg-sig is not supported by newer Debian versions.

For a Rust tool, cargo-deb builds the .deb from Cargo.toml metadata and the Cargo build output. It needs Rust 1.76 or later and writes target/debian/<name>_<version>-1_<arch>.deb. Assets default to installing the binary into /usr/bin/; depends defaults to automatically generated dependencies ($auto).

Source: cargo-deb. The project states that cross-compilation cannot target an older Debian release than the host; build on the oldest distribution you support, or link statically as described on Native Binaries & Cross-Compilation.

Scoop installs portable applications from JSON manifests kept in a bucket. The documented fields include version, description, homepage and license (all required), url, hash (SHA-256 unless prefixed), bin (executables added to the path), architecture (per 32bit, 64bit, arm64 overrides), checkver and autoupdate.

Source: Scoop — App Manifests. The page consulted links to a separate Buckets page for creating a bucket and does not describe checkver shortcuts or the autoupdate syntax in detail. The checkver value and the $version substitution in the example come from Scoop’s separate auto-update documentation, which was not consulted, so check them there before use.

Windows Package Manager manifests are YAML. A singleton manifest is valid only for a package with one installer and one locale; otherwise a multi-file manifest (version, default locale, installer and optional extra locales) is required. InstallerSha256 is required, every field is Pascal-cased and may not be duplicated, and the documentation states that all tools must support a silent install. Create manifests with wingetcreate new (installed with winget install wingetcreate), which can also submit the pull request to the community repository, or with the YAMLCreate.ps1 script of the winget-pkgs repository. Komac is a community tool with the same purpose; it is not described by the Microsoft documentation consulted.

Source: Microsoft Learn — Create your package manifest. The page consulted lists exe, msi, msix, inno, wix, nullsoft, appx and font as installer types in its minimal schema. The zip installer type with the NestedInstallerType, NestedInstallerFiles and PortableCommandAlias fields used above are not described by that page; take them from the manifest schema in the winget-pkgs repository and validate the manifest before submitting.

A Chocolatey package is a NuGet-style package whose only required element is the .nuspec. A self-contained package simply includes the executables, which Chocolatey shims onto the path automatically; Bob.exe.ignore skips a shim and Bob.exe.gui marks a GUI program. An installer script chocolateyInstall.ps1 (saved as UTF-8 with BOM) is only needed when something must be downloaded or run. The documented workflow is choco new, choco pack, a local test with choco install shelf --debug --verbose --source . (preferably in a virtual machine), then choco push with an API key. The community repository’s moderation rules include validating downloads with a checksum, a lowercase package identifier without dots, and a four-segment version.

Source: Chocolatey — Create packages.

Snaps are confined by default. Classic confinement is the most permissive level, giving access similar to a traditional package: no private mount namespace, no device cgroup, AppArmor in complain mode and no seccomp filtering. It exists for programs that need arbitrary host binaries, which a developer tool such as a CLI that launches compilers or git often does. The documentation states that a classic snap cannot be distributed without approval from the Store team and that Canonical audits them. The confinement page does not describe how users install a classic snap, so consult the Snapcraft documentation for the install command rather than assuming one.

Source: Snapcraft — Classic confinement and snapcraft.yaml reference. The reference page consulted lists the fields and the three confinement values (strict, devmode, classic) without explaining them; the base value, the dump plugin options and the build commands should be taken from the current Snapcraft how-to for your release.

An AppImage is a single file for Linux that users download, mark executable and run. A type 2 AppImage can be inspected with my.AppImage --appimage-extract (creates squashfs-root) or --appimage-mount. The distribution guide asks that the file name not contain linux, that AppImages are not wrapped in .zip or .tar.gz archives (which breaks desktop integration), that a stable URL without a version number is used for the catalogue, and that the host supports HTTP range requests when you want AppImageUpdate to work. The pages consulted do not describe a signing requirement, the FUSE requirement, or how update information is embedded; consult the Packaging Guide sections on optional features before documenting any of them for your users. AppImage suits GUI programs better than a terminal tool, which has no menu entry to integrate and is usually installed by a package manager.

Source: AppImage — Running AppImages and AppImage — Distributing AppImages.

Nix packages are functions that produce derivations. The nix.dev tutorial packages an existing program with stdenv.mkDerivation and a source fetched with fetchurl, whose hash starts empty: the first nix-build fails with a mismatch that reports the right value, which you then paste in.

Source: nix.dev — Packaging existing software. The tutorial’s skeleton builds with default phases; a real Rust or Go tool needs its language’s builder from nixpkgs, which the page does not cover. Getting a package into nixpkgs itself is a pull request to that repository and is not described on nix.dev’s tutorial page.