Repository navigation
FAQ
This FAQ addresses what Factory builds, how it compares with package build services, and where its YAML-driven workflow can be reused.
It builds three related artifacts or inputs:
- A package snapshot downloads selected binary
.debfiles from an APT repository and verifies each file's SHA-256 value. - A rootfs build creates a Debian-based filesystem from the fixed minbase baseline, the package roots in YAML, and their required dependencies.
- An ISO build takes a rootfs archive, applies an ordered set of packaged Nitrux stages, and creates a bootable image.
The snapshot is an input to repository publication; the rootfs archive is an input to the ISO build.
The YAML declares the APT repositories, a fixed minbase is installed first, and the top-level base list (or its packages alias) is added in a second transaction. APT installs the required dependency closure. Recommendations and suggestions are disabled, and the exclude list prohibits packages from both the baseline and dependency closure.
Repository priority and package Essential flags do not add unrelated packages to the fixed baseline. That keeps the package selection tied to the minbase definition and the YAML package roots.
No. The rootfs YAML supplies every repository URL, suite, component, architecture, and signing-key source. Factory does not infer or hardcode a distribution mirror. The snapshot target also reads its repository location from its own YAML document.
It is a separate rootfs bootstrap implementation. It uses Python-APT to read repository metadata, resolve package dependencies, and carry out APT package transactions in the target root. It also seeds the package runtime from the configured repositories, configures the fixed minbase, and then installs the YAML package roots. Likewise, it does not wrap either debootstrap or mmdebstrap.
The Open Build Service (OBS) is a build and distribution service for building binary packages and images from source across supported distributions and architectures. Its workflow includes source package recipes, build workers, repository publication, and project collaboration. See the OBS User Guide for its supported formats and workflows.
Factory is a local or CI-run rootfs and ISO assembly tool. It consumes binary packages already available through APT; it doesn't compile packages from source, host a general package repository, or provide OBS's project and worker services. The included GitHub Actions workflow is project automation around Factory, not a Factory build farm.
| Question | Factory | OBS | Launchpad PPA |
|---|---|---|---|
| Main input | APT repositories and YAML package/stage selections | Source packages and build recipes | Ubuntu source package uploads |
| Main work | Assemble rootfs archives and Nitrux ISOs | Build and publish packages and supported image formats | Build Ubuntu binary packages and publish them in an APT archive |
| Build infrastructure | Local host or a CI runner configured by the project | Hosted or self-managed build service with workers | Launchpad's hosted build farm |
| Repository hosting | Uses external APT repositories | Can publish build results through OBS projects | Hosts the resulting PPA packages |
A Launchpad PPA accepts source packages, builds binaries on Launchpad's build farm, and hosts them in an APT repository. Factory consumes binary packages from APT repositories and assembles rootfs and ISO outputs. It does not accept Debian source uploads or operate a PPA build farm.
You can use a compatible APT repository as a rootfs source, regardless of which service hosts it. Launchpad PPAs target Ubuntu packaging and suites; their package availability and dependencies must match the rootfs architecture and repository suite you configure.
The rootfs target is based on Debian APT. It can assemble a root filesystem from compatible APT repositories when the fixed minbase packages and requested packages exist for the selected architecture. You provide the repositories, keys, package names, exclusions, and output settings.
The ISO target is more specific: its shipped stages, boot files, and current flavors are for Nitrux. YAML can choose and order packaged stages but cannot add arbitrary shell stages. You can reuse the rootfs target for another Debian-based system; producing another distribution's ISO requires extending or adapting the packaged ISO stages.
No. APT selects and installs binary packages from the configured repositories. Use a package build service or a source-package tool to produce .deb files, then publish them to an APT repository that Factory can read.
No. factory snapshot downloads and verifies selected .deb files. The included GitHub Actions workflow separately yanks matching old packages and uploads the new snapshot to Nitrux Packagecloud before it builds the rootfs. The publishing credentials belong to that workflow, not to the snapshot command.
The CLI requires effective UID 0 for rootfs and ISO builds. UID 0 inside a rootless container can satisfy that check, but the container may not grant the capabilities needed by chroot, device creation, or mounts. The rootfs builder has device setup fallbacks, but it does not mount /proc or /sys for package installation. A package script that needs those facilities can still fail.
The ISO target consumes a rootfs archive, not a package repository. Build the rootfs archive first, then reference it locally or via a checksum-verified download in the ISO definition.
No. The stages list selects scripts shipped in the Factory package. YAML controls their order and which packaged stages run; it is not an inline shell-script interface. A custom distribution workflow requires changes to the packaged stages or a maintained fork.
The included Actions workflow publishes the rootfs archive and its SHA-256 sidecar to a GitHub Release after checking that the archive is below GitHub's 2 GiB per-asset limit. The ISO target produces ISO files locally. A larger ISO needs a host that accepts files of that size; repository and release hosting are separate from the build itself.
©2026 Nitrux Latinoamericana S.C.