ewpratten.com/content/blog/2023-07-05-simple-dnf-repo.md

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

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 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:

[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:

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:

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, 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.