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 stage files from an external asset directory, 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 does not compile those packages from source, host a general package repository, or provide OBS's project and worker services. Users provide their own build definitions and CI automation.
| 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 ISO images | 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 requires a compatible external asset directory containing the selected stages, boot files, and image-authoring tools. Its current flavor handling supports Mesa and NVOpen. Reusing it for another distribution requires supplying suitable assets and build definitions.
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. Publishing packages to an APT repository is handled by the project that owns the repository and its automation.
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 names files in the external ISO asset directory; it does not embed shell script contents in YAML. The asset directory and build definition are supplied by the project using Factory.
Factory creates build artifacts locally and does not publish them. The project using Factory chooses how and where to distribute rootfs archives, package snapshots, and ISO images.
©2026 Nitrux Latinoamericana S.C.