Tutorials on SOW

Build a YUM Repository

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial builds a production-shaped RPM repository from scratch. By the end you will have a workspace holding a pigsty repository with an el9 Dist, two architecture views rendered from one package pool, debuginfo noise filtered out, only the newest version of each package kept, and a .repo file that dnf accepts.

Plan for about fifteen minutes. Every command runs locally; nothing talks to the network.

Before you start

You need three things.

Build an APT Repository

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial builds a managed APT repository: a Debian-style package pool grouped by source package, one index per architecture, by-hash index copies so clients never race a rebuild, and client configuration in both the modern deb822 format and the legacy one-liner.

Plan for about fifteen minutes.

Before you start

You need SOW installed (Installation), some .deb files, and a directory you can write to.

This tutorial continues from Build a YUM Repository by adding a second Dist to the same pigsty repository — one pool, two package ecosystems. If you are starting fresh, run these three commands first and then continue from Step 1:

Sign Your Repository

Mon, 01 Jan 0001 00:00:00 +0000

An unsigned repository is a repository anyone on the path can rewrite. This tutorial closes that hole: you generate a signing key, configure SOW to sign what it publishes, verify the signatures by hand, and turn on client-side enforcement so dnf and apt refuse anything that does not check out.

Plan for about twenty minutes.

Two independent trust chains

Package repositories have two things worth signing, and they are not the same thing.

Serve Repositories

Mon, 01 Jan 0001 00:00:00 +0000

SOW builds a static directory. Anything that can serve static files can serve it — there is no daemon, no application server, and no runtime component. This tutorial covers what to point a web server at, a tested Nginx configuration, a one-command local preview, and how to move the tree to a host that cannot reach your build machine.

Plan for about fifteen minutes.

What you actually serve

For a managed workspace, the document root is the repository directory:

Migrate from createrepo_c / reprepro

Mon, 01 Jan 0001 00:00:00 +0000

You already have a repository. This tutorial replaces the tool that builds it without breaking the clients that consume it — including the leftover files nobody warns you about and the layout differences you should know before, not after.

Two paths, depending on what you have. Read the one that matches, then the comparison at the end.

Choose your target

You have	Migrate to	Read
`createrepo_c` on a directory of RPMs	Plain mode, in place	Path A
`dpkg-scanpackages` on a flat DEB directory	Plain mode, in place	Path A
A reprepro archive with `pool/` and `dists/`	Managed workspace	Path B
`createrepo_c` plus scripts for multiple architectures	Managed workspace	Path B

Plain mode is the drop-in replacement: same directory, same URLs, one command instead of a toolchain. Managed mode is a change of shape — a workspace, a pool, per-architecture views — and gives you membership policy, transactional builds, and an audit trail. Migrate to Plain first if you just want the dependency gone; move to Managed when the repository’s lifecycle is what hurts.