Packages

Custom tooling ships as real .deb packages through the Nexus APT repository at https://nexus.toolsera.lan/repository/toolsera/, rather than as scripts copied between hosts. Hosts get access to it through the custom_apt_repo Ansible role.

Current packages

Package	Mode	What it is
`netshare-mounter`	`fpm`	CLI that configures SMB/CIFS mounts as systemd mount units — docs
`qbt-tracker-remover`	`fpm`	qBittorrent tracker cleanup as a systemd service, with a `configure` subcommand
`hello-toolsera`	`dpkg`	Minimal reference package, useful for testing the pipeline end to end

Two build modes

Every package carries a package.yml manifest, and build.sh dispatches on its mode: field:

mode: dpkg — you maintain a DEBIAN/control tree and the package is assembled with dpkg-deb. Version lives in both package.yml and DEBIAN/control.
mode: fpm — the package is assembled entirely from manifest fields (files:, depends:, description:, and so on). Version lives only in package.yml.

cd packages/debian-ubuntu

./build.sh <package-name>                            # local build
./build.sh <package-name> --expected-version 1.0.1   # CI-style strict version check

Releasing

Bump version: in package.yml — and the Version: line in DEBIAN/control too, for mode: dpkg packages
Commit and merge to main
Push a tag shaped pkg/<package>-<version>, for example pkg/hello-toolsera-1.0.1

The publish-package.yml GitHub Actions workflow then runs on the self-hosted homelab,deb-builder runner, builds the .deb, uploads it to Nexus under bws run, triggers Nexus to rebuild APT metadata, and attaches the artifact to a GitHub Release. workflow_dispatch is wired up for manual reruns.

Where to go next

Building & releasing packages — the full reference
build.sh reference — CLI, both build modes, manifest schema, exit codes and troubleshooting
FPM packaging guide — FPM as a tool
Package testing guide — verifying a package before it ships