Packaging Ecosystem

This document explains how Garden Linux packages are built using the tools in the package-build repository and how they fit into the broader packaging ecosystem.

Release Hierarchy

Garden Linux uses a three-tier release hierarchy to deliver a complete operating system.

This document is about the first tier, the Packaging.

Package Build Tools Repository (package-build)

The package-build repository provides:

• Standardized build scripts for creating Debian packages
• GitHub Actions workflows for automated building
• Common functions and utilities used by all package repositories
• Documentation for local and CI-based package building

Source Package Repositories (package-*)

Each custom-built package has its own GitHub repository following the naming convention package-{package_name} (e.g., package-containerd, package-openssh). These repositories contain:

• The source code or references to upstream sources
• Build scripts and configuration
• Debian packaging files (debian/ directory)
• Package-specific build instructions

These repositories are built using the tools in the package-build repository.

Package Flow Process Overview

1. Source Management: Package source lives in package-{package_name} repos
2. Building: Packages are built using tools from package-build repo
   • Can be done locally or via GitHub Actions
3. Release Assembly: Built packages are collected and assembled into APT repositories by the repo workflow
4. Distribution: Final APT repository is published and made available to users

Key Relationships

• Each package-* repo declares its build dependencies in its source
• The package-build repo provides common tooling used by all package-* repos
• The repo orchestrates the final release by collecting built packages and dependencies
• Users access packages through the standard APT system pointing to Garden Linux repositories

Understanding Package Versions

Garden Linux packages typically follow versioning like:

<upstream_version>-<debian_revision>~gardenlinux<sequence>

For example: 1.2.3-1~gardenlinux0

Where:

• 1.2.3 is the upstream version
• -1 is the Debian revision
• ~gardenlinux0 indicates this is the first Garden Linux rebuild

When creating patch releases or backports, the suffix is incremented (e.g., ~gardenlinux1, ~gardenlinux2) or modified for specific use cases (like ~bp1443 for backports).

Related Topics

• Release HierarchyOverview of Garden Linux Release Hierarchy
• Package SourcesLearn about different types of Garden Linux Package Sources
• Repository InfrastructureUnderstand how Garden Linux assembles, distributes, and releases packages through its repository infrastructure
• OS ReleasesUnderstanding Garden Linux OS release artifacts, distribution channels, and orchestration
• Semantic VersioningHow we Version Garden Linux Releases
• Creating Package ReleasesComprehensive guide to creating Garden Linux Package releases
• Local Package BuildingLearn how Garden Linux Packages are built locally
• Github Actions Package BuildingLearn how Garden Linux Packages are built in Github Actions
• Creating PackagesLearn how to create Garden Linux Packages
• Patch Releases and BackportingLearn how to update and backport Garden Linux Packages
• PatchingLearn how to create and update Patches for Garden Linux Packages
• Build DependenciesLearn how to create and manage one-shot build dependencies
• NULL ReleasesLearn how to use NULL releases to exclude Packages frin Garden Linux builds
• Packaging RulesReference of all authoritative Garden Linux Packaging Rules