Package build reference

On this page

How a package enters an OnixOS repository

The build system selects package projects through its configured lists. Each package project supplies a PKGBUILD and any source files, patches, service units or install scripts it needs.

Build list	Repository	Contents
sources/base.list	onix-base	Base utilities, graphics, installers and O Language packages
sources/community.list	onix-community	Community applications and desktop utilities
sources/kernel.list	onix-kernel	Linux Onix kernel packages
sources/firmware.list	onix-firmware	Additional firmware packages

The list chooses what to build; the package’s PKGBUILD defines the package metadata, dependencies, supported architectures and build steps. A package directory that is not selected by an active list is not automatically published.

PKGBUILD metadata

A PKGBUILD is a Bash build description consumed by makepkg. These fields define the package contract:

Field	Purpose
pkgname or pkgbase	Binary package name, or source base name for split packages
pkgver	Upstream version
pkgrel	OnixOS package recipe revision; increment it for packaging-only changes
epoch	Optional override when version ordering needs a reset
pkgdesc, url, license	Package description and project metadata
arch	Architectures that can use the resulting package; use any only for architecture-independent output
depends	Runtime dependencies
makedepends	Build dependencies not needed at runtime
checkdepends	Dependencies needed by the check function
optdepends	Optional features and their suggested dependencies
source and integrity arrays	Source URLs or local files, with checksums or source signatures
backup, conflicts, provides, replaces	Package installation and dependency-resolution behavior
install	Optional install script placed beside the PKGBUILD

For example, the OnixOS kernel recipes use a source base and split package functions to produce the kernel and its headers. A single PKGBUILD can therefore emit more than one binary package.

The complete directive list and parsing rules are in PKGBUILD(5).

Build functions

A recipe can define these functions:

Function	When it runs	What belongs there
prepare()	After sources are downloaded and extracted	Apply patches and configure the source tree
pkgver()	For version-control sources when the version is derived from the checkout	Print the package version
build()	Before packaging	Compile or generate the software
check()	When package checks are enabled	Run upstream or package-specific checks
package()	After the build	Install files into $pkgdir
package_name()	For a split package	Install one named package from the shared build

Keep downloaded source validation in the PKGBUILD integrity arrays. Do not use SKIP for ordinary release archives; use it only when the source type or upstream workflow cannot provide a stable checksum, and document that choice.

Architecture support

The OnixOS repository build system has package targets for x86_64, aarch64 and armv7h. The package itself must list each supported target in arch, and its source and dependencies must build there. A repository target cannot make an x86_64-only package usable on ARM.

Use arch=(‘any’) only when the installed files contain no architecture-specific binaries. For compiled packages, declare the architectures that the recipe has been built and checked for.

Local package workflow

Work from the package project directory on an Arch-based build host. Review the recipe and its local files before building:

less PKGBUILD
makepkg --verifysource
makepkg --syncdeps --cleanbuild
makepkg --printsrcinfo > .SRCINFO

makepkg builds as an unprivileged user. The resulting package archive can be installed locally for a test with pacman, but that does not publish it to an OnixOS repository. See makepkg(8) for options.

Build through onix-build-system

The repository pipeline builds the packages selected by a repository list for the requested architecture. From the root of the onix-build-system checkout:

python build.py repos --arch=x86_64 --repo=onix-base

Replace the repository and architecture with the intended target. The package’s arch metadata is checked during the build. Repository artifacts are written under:

output/repos/<architecture>/<repository>/

The repository stage updates its package database after collecting built archives. The build system guide and build reference document the other stages and output paths.

Source and package identity

A source project name does not always match the binary pkgname. Before writing dependencies, profile package lists or update instructions, inspect the PKGBUILD and generated .SRCINFO. Use the binary package name for pacman dependencies and the project name in the build-system package list.

For package management after installation, see pacman and opkg. For published repository URLs, see repository configuration.