---
title: How I manage Suckless software installations
date: 2025-11-30
layout: post
---

Since <a href="https://suckless.org/" class="external" target="_blank"
rel="noopener noreferrer">suckless</a> software requires users to modify the
source code and recompile to customize, I need a way to maintain patches over
the long term while retaining the ability to upgrade the software as new
versions are released.

## Initial setup

When using a suckless program, I usually begin by cloning the project and
setting the remote push URL to my own git repository:

```
git clone git://git.suckless.org/dwm
git reset --hard <tag>
git remote set-url --push origin git@git.asciimx.com:/repos/dwm
```

This way, I can pull updates from the upstream project whenever I want, while
committing my changes to my git repository. The git reset command aligns my
branch head with a stable release before applying patches or installing the
software.

If all I want to do is reconfigure the software (e.g., change key bindings),
which is what I need most of the time, the recommended approach is to modify
the config.h file. If the config.h isn't yet in the project, the 
`make clean <target>` command will generate it from the defaults and compile
the software. The `<target>` is the name of the application (e.g., dwm) found
in the Makefile. I modify the resulting config.h file and run `make clean
install` to install the software before committing and pushing my changes to
the git repo.

## dwm and slstatus

Since dwm and slstatus are always running, `make install` will likely fail for
them. The operating system may prevent the installer from replacing running
executables with new ones. Hence, we must first stop the running instances of
these programs (in my case, using Mod + Shift + q). Then, switch to a tty 
(Ctrl + Alt + F1), log in, and change the directory to where dwm/slstatus is.
We can run `make install` to install the software and switch back to the
graphical session (Ctrl + Alt + F5).

The key combinations for switching to the tty and back may differ across
systems. The ones listed above are for OpenBSD.

## Subsequent upgrades

When suckless releases a new version, I run `git pull --rebase` to fetch the
upstream changes and rebase my patches on top of them. Because I tend to use
stable versions, I perform another interactive rebase to drop the commits
between the latest stable version tag and my patch before installing the
software.

Commit log before upgrading:

```
dt236  My patch.
3fkdf  Version 6.5.
```

Commit log after pulling:

```
w467d  My patch.
gh25g  A commit.
g525g  Another commit.
3fkdf  Version 6.6.
vd425  Old commit.
q12vu  Another old commit.
3fkdf  Version 6.5.
```

Commit log after the interactive rebase:

```
h57jh  My patch.
3fkdf  Version 6.6.
vd425  Old commit.
q12vu  Another old commit.
3fkdf  Version 6.5.
```

And finally, I commit and push all the changes to my git repository.