ORB: the ORB RPM Build system

One Spec, Many Deployments

RPM spec as a unified build definition for CI/CD pipelines, testing, and deployment across package repositories, software collections, and containers.

A Unified Path from Source to Deployment

RPM spec files provide a consistent, proven build definition that works across your entire pipeline. Write your spec once, then build and test in CI, deploy to package repos, create portable collections, or package for containers—all from the same source of truth.

Why RPM Spec?

RPM spec is a mature, standardized format for describing how to build software. It handles dependencies, build steps, installation paths, and package metadata in a declarative way. Unlike fragmented tooling where you define builds differently for each deployment target, RPM spec gives you one definition that adapts to multiple deployment types through build-time configuration.

Same Spec, Multiple Deployment Targets

The power of RPM spec lies in its flexibility. Configure your deployment type at build time, and the same spec adapts to produce the right output.

📦

Package Repositories

Traditional YUM/DNF repositories for distribution-wide deployment. Perfect for system packages and infrastructure components.

See Configuration
# build-assist.yaml
base: fedora-39-x86_64

build:
  - type: dist-git
    url: https://src.fedoraproject.org/rpms/
    packages:
      - nginx:f39
      - postgresql:f39
      - redis:f39

# Creates standard RPM repository

→ Same spec, standard install paths

📚

Software Collections

Portable, self-contained application bundles with rpath. Deploy across distributions with compatible libc without package manager integration.

See Configuration
# build-assist.yaml
base: fedora-39-x86_64

build:
  - type: git
    url: https://github.com/myorg/
    packages:
      - python312:main
      - python312-pip:main
      - python312-flask:main

install:
  type: software-collection
  collection: python312
  packages:
    - python312
    - python312-pip
    - python312-flask

# Installs to /opt/python312 with rpath

→ Same spec, /opt prefix + rpath

📱

Flatpak Applications

Sandboxed desktop applications with automatic dependency bundling and runtime isolation.

See Configuration
# build-assist.yaml
base: fedora-39-x86_64

build:
  - type: git
    url: https://github.com/myorg/
    packages:
      - myapp:main
      - myapp-plugins:main

install:
  type: flatpak
  packages:
    - myapp
    - myapp-plugins

# Installs to /app prefix

→ Same spec, /app prefix

🐳

Container Images

Build container-ready packages with proper metadata and dependency chains for optimal layer caching.

See Configuration
# build-assist.yaml
base: fedora-39-x86_64

build:
  - type: dist-git
    url: https://src.fedoraproject.org/rpms/
    packages:
      - nginx:f39
      - webapp:main

install:
  type: container
  packages:
    - nginx
    - webapp

# Optimized for container layers

→ Same spec, container-optimized

⚡

CI/CD Testing

Use the same build definition in your continuous integration pipeline to ensure what you test is what you deploy.

See Configuration
# build-assist.yaml - CI mode
base: fedora-39-x86_64

build:
  - type: git
    url: https://github.com/myorg/
    packages:
      - webapp:${GIT_BRANCH}
      - webapp-tests:${GIT_BRANCH}

# Build from current branch
# Run tests with same build process
# No "works on my machine" issues

→ Same spec, current branch

🚀

Development Builds

Build directly from source repositories without a release process. Perfect for rapid iteration and testing upstream changes.

See Configuration
# build-assist.yaml
base: fedora-39-x86_64

build:
  - type: git
    url: https://github.com/myorg/
    packages:
      - webapp:main
      - webapp-api:main

# Builds from HEAD
# No tags or releases needed
# Deploy bug fixes immediately

→ Same spec, no release process

Benefits of a Unified Build Definition

When your entire pipeline uses the same build definition, friction disappears.

Consistency Across Environments

Development, testing, staging, and production all use the same RPM spec. No more "it works in dev but fails in prod" because builds differ.

Reduced Friction

Following stable upstream releases directly reduces friction between developers and users. Bug fixes flow to production without manual repackaging.

Lower Maintenance Overhead

Automated tracking of upstream releases means maintainers focus on code, not on manually updating package definitions across multiple systems.

Deployment Flexibility

Choose your deployment method based on user needs, not build system constraints. Switch between repos, collections, and containers without rewriting specs.

Proven Technology

RPM has powered enterprise Linux distributions for decades. It's mature, well-documented, and supported by extensive tooling.

Monorepo-Like Velocity

Building from source-git repos removes release processes from deployment pipelines, giving you monorepo benefits while maintaining package boundaries.

Supporting Automation

ORB provides tools to automate the maintenance and building of RPM-spec-based pipelines.

dist-git-manager

Automates dist-git repository maintenance: monitors upstream releases, updates specs, manages SemVer release branches.

source-git-manager

Mirrors upstream repositories and manages release branches with RPM specs for building directly from source.

rpm-build-assist

Builds RPM packages from dist-git or source-git with support for multiple deployment types via build-time configuration.

Docker vs RPM Comparison →

See how RPM-based builds compare to traditional Dockerfiles in complexity, maintainability, and reusability.

Portable Applications →

Build self-contained application bundles using package collections that run across different Linux distributions.

Ready for a Unified Build Pipeline?

Use RPM spec as your single source of truth from CI to deployment.

View on Codeberg