OOskar Karpiński
Back to projects
Active development

Pako — a package manager for Linux applications

Pako is a package manager I am developing for large, self-contained Linux applications. It provides a consistent way to install and update software distributed by vendors as archives without requiring administrator privileges.

01

Problem

Large Linux applications are often distributed as complete archives. Users have to download, extract, configure and install the files themselves, repeat the process for every release and track which version is active.

This manual workflow makes rollback harder, can leave old files behind and provides no automatic integrity verification. An interrupted update can also damage the active installation.

02

Solution

Pako introduces a consistent model based on simple recipe.toml recipes and complete payload.tar.zst archives. It downloads a release, checks its integrity and prepares it in a versioned directory.

A new version is activated only after the process completes successfully. Installation happens in user space without sudo, with state retained for updates, removal and rollback.

03

Architecture

Pako consists of a library containing installation and state-management logic, the user-facing pako CLI and the pako-build tool. The shared core handles recipe parsing, downloads, integrity checks and version operations.

Separating the command interface, build process and domain logic allows each element to evolve without duplicating the rules governing packages and installation state.

recipe.toml

pako-build

Shared core

Rust library

pako CLI

04

Simple package format

A recipe.toml file describes the application source, version, architecture, checksum, payload preparation, executable files and user environment integration. A finished release is one compressed payload.tar.zst archive.

The project previously experimented with fragmented data and packs. Testing showed that the additional complexity did not provide enough benefit, so the architecture was deliberately simplified.

recipe.toml

name · versionsource · archchecksum · bins

payload.tar.zst

ZstandardSHA-256 checksumFull payload

05

Installation and updates

Pako downloads metadata and a payload, verifies both and extracts the application into a separate version directory. Only a complete and checked release can become the active version.

This flow separates preparation from activation. The previous version does not have to be overwritten during an update and can remain available as a rollback point.

01

Download

02

Verification

03

Prepare version

04

Activation

User space · XDG · no sudo

06

Safety and reliability

Installation runs in user directories without administrator privileges. SHA-256 checks protect downloaded data integrity, while versioned directories reduce the risk of leaving an application partially updated.

State recovery after interrupted operations remains one of the project's goals. Specific behaviours are still evolving and are not presented as completed guarantees of a stable release.

Previous version

app/1.4.0

New version

app/1.5.0 → active

SHA-256 ✓Rollback ↩

07

Challenges

The main challenges are designing a safe installation process, managing versions without administrator privileges, verifying integrity and recovering from interrupted operations.

XDG integration, clear CLI messages and an understandable recipe format are equally important. The project regularly requires deciding whether a new feature genuinely justifies its additional complexity.

What it taught me

Key takeaways

Pako is expanding my experience in system tooling, safe file operations and simplifying architecture based on test results.

01

Rust and system tooling

The project requires deliberate handling of errors, paths, processes and file operations in Rust.

RustCLILinux
02

Data integrity

Verifying downloaded metadata and payloads is part of the installation process rather than a step added afterwards.

SHA-256ZstandardVerification
03

Transactional file operations

A new version should be prepared and checked before activation to reduce the risk of leaving an application partially updated.

VersioningRollbackReliability
04

Simplicity as an architectural decision

Tests of earlier ideas showed that a simple full payload is a better trade-off for the target applications than unjustified complexity.

TestingTrade-offsDesign

Code and context

Explore the project repositories

The source code, documentation and development history of Pako remain public as reference material.