How I manage Suckless software installations

HOW I MANAGE SUCKLESS SOFTWARE INSTALLATIONS

30 NOVEMBER 2025

+
+

Since suckless 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.

+ +

by W. D. Sadeep Madurange