--- title: How I manage Suckless software packages date: 2025-11-30 author: Wickramage Don Sadeep Madurange layout: post --- 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 URL to push a copy of the source code with my patches to my own git repository: ``` git clone git://git.suckless.org/dwm git reset --hard 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 own 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 following command generates it from the defaults and compiles the software using `make clean ` here `` 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 my git repo. ## dwm and slstatus Since dwm and slstatus are always running, `make install` will likely fail for them. The operating system will prevent the installer from replacing running executables with new ones. Hence, we must first stop the running instances of these programs (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, commit and push all the changes to my own git repository.