Building from Source & Package Management

InterGenOS is built from source. Every package that ships in the system was compiled from upstream code in an isolated build environment, recorded with content hashes, and deployed by a package manager that can later prove each file on disk is exactly what was installed. This section explains how that pipeline works and how you can inspect, rebuild, or extend it yourself.

This is the practical expression of the project’s posture: a machine you understand, can modify, and can trust.

The two halves of the system

InterGenOS package handling splits cleanly into a factory and a consumer:

• igos-build is the factory. It constructs packages from source code in an isolated environment and produces binary archives (.igos.tar.gz).
• pkm is the consumer. It runs against the live filesystem, installing, removing, querying, and verifying those archives. It records every deployed file in a database that doubles as an audit trail.

igos-build compiles source and generates the initial file list and hashes. pkm is the command-line tool end users run to download and install the resulting archives, and to confirm at any later time that nothing on disk has drifted from what was installed.

See The Transparent Package Manager for pkm in depth, and Building Packages from Source for the build side.

How the system is assembled: the build tiers

The full system is organized into seven tiers, built in dependency order. The counts below are stated as round-down thresholds, not exact figures — they drift as packages are split, added, or merged, so derive the live figure rather than quoting this table.

A package definition existing is not the same as that package shipping on the installed image. Each tier has a default: extra and compute default to mirror-only (installable from the repository, absent from the image), and every other tier defaults to shipping on the image. Individual packages override that default either way, so the two columns below are counted from the effective value rather than assumed from the tier.

The ai tier is the clearest example of why the distinction matters: it holds over 50 definitions, but only two of them — the assistant itself and the llama.cpp inference engine — ship on the image. The rest are the mirror-only model-tooling stack (PyTorch, Transformers, and their dependencies), installable on demand and absent from a default installation.

The whole compute tier is mirror-only: no package in it ships on the image.

To derive the current figures yourself from a checkout of the source tree, count the definitions per tier and read the effective iso_include value; the tier default is set in the build system’s package parser.

The build pipeline

A full image build runs through 21 phases in fixed order, with an optional publish step at the end:

1. validate
2. verify-sources
3. setup
4. toolchain
5. chroot-prep
6. chroot-tools
7. core
8. config
9. core-extra
10. base
11. kernel
12. desktop
13. extra
14. compute
15. ai
16. bootloader
17. image
18. manifest
19. squashfs
20. ukis-verity
21. iso

Source verification happens before any compilation. Image, manifest, squashfs, UKI/verity, and ISO assembly happen after the package tiers are built, so the final artifact carries an integrity chain from the verified sources through to the bootable image.

What this gives you

Because the package manager records a SHA-256 hash for every file it deploys, you can ask the system to re-verify itself at any time. The pkm verify command recalculates the hash of every installed file on disk and compares it against the expected hash, detecting both accidental corruption and unauthorized modification. Package state lives in a SQLite database for fast queries and, alongside it, human-readable text manifests for direct inspection. The same record-keeping that makes the system fast makes it auditable.

Upgrades use a “supersede” model rather than blind overwrites, so package splits (for example, separating a tool’s core utilities from its extras) happen without orphaning files or breaking dependencies. Configuration files under /etc/ are tracked separately and preserved across changes, so your local modifications are not silently discarded.

What ships today

• pkm, the package manager described above.
• Forge, the system installer. See the FORGE Installation Guide.
• A signed Secure Boot chain, dm-verity integrity over the read-only system image, and UKI signing, covered in Verified Boot & Secure Boot.
• GNOME 49 on Wayland as the desktop environment (GNOME Shell 49.4).
• InterGen, a tiered, hardware-detected, offline-first local assistant built on an on-device model, with zero telemetry. See The AI Assistant.
• InterGen Sentinel, a pluggable security scanner defaulting to Local-Rules and Local-Qwen, with six named opt-in cloud providers available via “Phone-A-Friend” (Frontier/Cloud Escalation): Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek. A seventh option accepts any custom OpenAI-compatible endpoint, so you are not restricted to the named six. All seven are off unless you configure one, and an API key never enters the configuration file: the key goes to the system keyring, and only its keyring identifier is written to the per-user config (mode 0600).

KDE/Plasma and Qt6, switchable desktops, and dedicated application campaigns (for video, graphics, CAD, finance, virtualization, and similar) are planned and not part of the current system. This section documents only what ships today.

In this section

• The Transparent Package Manager — how pkm installs, removes, queries, and verifies the live system.
• Building Packages from Source — the igos-build factory and how to compile a package yourself.
• Repositories, Mirrors & Self-Hosting — where archives come from and how to serve your own.
• Reproducibility & Verification — confirming a build matches its sources and that installed files match the record.
• Package & Config Reference (generated) — the generated catalog of packages and tracked configuration.