---
title: Setting up a static DNF repository
description: Hosting RPMs is less painful than I expected
date: 2023-07-05
tags:
- linux
- walkthrough
draft: false
extra:
  auto_center_images: true
  excerpt: Information on how I set up dist.ewpratten.com, my DNF repository
aliases:
- /blog/simple-dnf-repo
---

<!-- I regularly find myself bouncing between wanting to *self-host all the things* (because it is fun), and use well-known hosting services (because I generally have better things to do with my time). I doubt I'll ever actually pick one side or the other, but I have found that the back-and-fourth of `hosted, diy, hosted` leads me to learn a lot about the tools I use. -->

Whenever I start using a new tool/system/library, I tend to inadvertently follow this pattern:

- Do it "correctly"
- Do it myself
- Decide that doing it correctly was the right choice in the first place and switch back

An example of this process is: I'll find myself using some hosted service, decide I want to self-host and learn about how it all works in the backend, then eventually decide that the effort of keeping the thing running isn't worth my time and switch back to the hosted service.

I say this as I know I'm in step 2 right now with RPM hosting.

## I wanted to publish RPM packages for my applications

I realize that I take commands like `cargo install` and `python3 -m pip install` for granted. Of course other developers have these tools installed (and know how to use them), so I got in the habit of just publishing apps to developer-focused package repositories like crates.io and PyPI.

At the time of writing this, I have somewhere between 50 and 100 desktop applications published in various corners of the internet that all require their own tools to download.

As a first step to making my applications a bit more user-friendly I wanted to properly package my work in formats consumable by default package managers. Since I (and my close friends) use Fedora, the [RPM format](https://en.wikipedia.org/wiki/RPM_Package_Manager) was the obvious first choice.

## `.repo` files

DNF (and YUM) uses `.repo` files to describe all the available software repositories on a system. These files are stored in `/etc/yum.repos.d/` and contain a few key pieces of information:

- The name of the repository
- A URL to the repository root
- A boolean indicating if the repository is enabled by default
- Some additional options for signing keys and other metadata

The definition for my public fedora repo looks like this:

```ini
[ewpratten]
name = Evans Software Repository
baseurl = https://dist.ewpratten.com/linux/fedora/$releasever/$basearch/stable
enabled = 1
gpgcheck = 0
```

The `baseurl` option supports some variables, so I personally have separate directories on my fileserver for each fedora release and architecture. This lets me release packages that target specific versions of Fedora, and I can easily add support for new versions as they are released.

On my current desktop, the actual URL that is constructed works out to be:

```text
https://dist.ewpratten.com/linux/fedora/38/x86_64/stable
```

## Actually setting up a repo

The next (and pretty much final) step is to create a repository somewhere.

This was as simple as spinning up a webserver and running:

```bash
mkdir -p /path/to/www/linux/fedora/38/x86_64/stable
createrepo /path/to/www/linux/fedora/38/x86_64/stable
```

Ya. That's it. I added a `Packages` subdirectory, tossed in a few RPM files generated by [cargo-rpm](https://crates.io/crates/cargo-rpm), re-ran `createrepo` and suddenly my desktop could install each of my applications through `dnf`!

## Check out my repo

For now, since I don't have many packages published, I'm storing my repository in GitHub pages. You can check out the files powering the repo [here](https://github.com/ewpratten/distribution).