Managing packages in Slackware in 2026.

These days, I only write articles about the various workflows that I have implemented and improved over time to manage various aspects of my day at the computer 😎

Today, it’s about the workflow I follow to manage my Slackware packages. You can find the repository at the top of the menu, or by clicking the button below:

// My Repos

Most of the scripts I write follow the standards of slackbuilds.org, except where it is impossible to apply them. I manage the slackbuild repositories on GitHub, where I maintain:

• a repository of personal packages (packages that are not on SBo or that have specific compilation flags, sources from git repositories, etc.)
• a repository of packages revolving around cybersecurity, with some packages published by me or others on SBo, while others are only on the personal repo.

// Compiling Packages

To compile the packages, I use 2 separate VMs, one running slackware64-current and one running slackware64 15.0, both kept up to date and with the SBo repositories, as well as a local clone of my 2 repos, of course.

I only use the virtual machine with slackware -stable to test the compilation of those packages that I decide to publish on SBo, mainly to verify the dependencies and that the compilation is successful.

The machine with -current, on the other hand, is the one I use most often, as it is the one that generates the packages that I also use on my physical computer; the same packages that I then publish on packages.

To compile the packages, I rely on slackrepo, a program originally written by David Spencer (aka idlemoor), and whose development has recently been taken up by Andrew Clemons (aka aclemons). Thanks to slackrepo, I can compile even complex packages cleanly, as it uses chroot to install the necessary dependencies and, once the packages are compiled, through hooks, I can have it execute other scripts that generate the repository files and upload the files directly to my web space.

// The repo for slackrepo

Slackrepo allows you to manage slackbuild repositories like the one on SBo, or like the one for -current managed by Matteo Bernardini (aka Ponce). In particular, I clone the repo for current, create a local branch, insert my 2 repositories as submodules and then delete the packages that would conflict, do a rebase with my changes keeping everything locally and on this modified repo I make slackrepo operate.

// The initial setup is as follows:

1
2
3
4

git clone https://github.com/Ponce/slackbuilds.git /var/lib/sbopkg/SBo-danix
cd /var/lib/sbopkg/SBo-danix
git checkout current
git checkout -b danix-current

Then I add my personal repos:

1
2
3
4

git remote add my-slackbuilds https://github.com/danixland/my-slackbuilds.git
git remote add my-pentesting https://github.com/danixland/Slackware-Pentesting-Suite.git
git subtree add --prefix=personal my-slackbuilds main --squash
git subtree add --prefix=pentesting my-pentesting main --squash

so that I have my repos as sub-directories personal/ and pentesting/.

// Daily Operations

I have a hook for slackrepo that does the following each time:

1
2
3

cd /var/lib/sbopkg/SBo-danix
git fetch origin
git rebase --rebase-merges -X theirs origin/current

the --rebase-merges option ensures that my files remain within the subfolders where I have placed them, while -X theirs automatically resolves any conflicts in the .gitignore file in favor of my version so that the rebase is not blocked.

If during the day I have uploaded changes to one of my repositories on GitHub, I just need to do:

1
2

cd /var/lib/sbopkg/SBo-danix
git subtree pull --prefix=personal my-slackbuilds main --squash

to retrieve the changes in my VM.

// Conflict Management

Since I maintain packages in my personal repos, which are also present on SBo, I must avoid having duplicates so that slackrepo always knows where to take the sources for the packages that I need to compile.

// Version bump

If a package simply needs to be updated, I just need to create a hintfile for slackrepo with the new version, the new download link and the updated md5sum, and slackrepo will compile the package with my version, without having to wait for the maintainer to update on SBo.

A hintfile is based on the .info file for that package and overwrites its information:

1
2
3
4

# /etc/slackrepo/SBo-danix/hintfiles/development/hugo/hugo.hint
VERSION="0.159.2"
DOWNLOAD_x86_64="https://github.com/gohugoio/hugo/releases/download/v0.159.2/hugo_extended_0.159.2_Linux-64bit.tar.gz"
MD5SUM_x86_64="a3e27d4b2049a710dbe7d7c1954a827e"

// SlackBuild fix

If, on the other hand, I need to modify a SlackBuild of a package more deeply, I will make a copy of it in my personal repository, and remove the copy from SBo

1
2
3

cd /var/lib/sbopkg/SBo-danix
git rm -r category/pkgname
git commit -m "pkgname: shadow with fixed version from personal/"

without needing a push to git, I work on a personal local branch. When Ponce from upstream updates the package in question, during the rebase I will see a conflict, and I can verify if the update has been inserted and remove my personal version in favor of the upstream version.

1
2
3

git rm -r personal/pkgname
git commit -m "pkgname: drop local shadow, fix merged upstream"
git subtree push --prefix=personal my-slackbuilds main

As for the basic management, that’s all, in the next article we will see how to manage a local and remote package repository using some very convenient shell scripts.

See you soon 😉