1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
+++
title = "Managing packages in Slackware in 2026."
date = "2026-05-04"
type = "tech"
image = "/uppies/2026/05/ascii-1920x1080.png"
excerpt = "My updated workflow for managing packages in Slackware64 current."
tags = ["linux", "git"]
categories = ["Code", "DIY"]
+++
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 :sunglasses:
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:
{{< Actions url="https://packages.danix.xyz" desc="packages.danix.xyz" use="site" caption="my Slackware Packages Repository" >}}
## My Repos
Most of the scripts I write follow the standards of [slackbuilds.org](https://slackbuilds.org/guidelines/), except where it is impossible to apply them. I manage the slackbuild repositories on GitHub, where I maintain:
- a repository of [personal packages](https://github.com/danixland/my-slackbuilds) (packages that are not on SBo or that have specific compilation flags, sources from git repositories, etc.)
- a repository of [packages revolving around cybersecurity](https://github.com/danixland/Slackware-Pentesting-Suite), 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**.
{{< callout type="warning" >}}
All the packages in [my repository](https://packages.danix.xyz) are compiled for slackware64-current and will not work on slackware64-stable.
{{< /callout >}}
To compile the packages, I rely on [slackrepo](https://github.com/aclemons/slackrepo), a program originally written by [David Spencer](https://github.com/idlemoor/) (aka idlemoor), and whose development has recently been taken up by [Andrew Clemons](https://github.com/aclemons) (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](https://github.com/Ponce/) (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:
```bash
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:
```bash
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:
```bash
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:
```bash
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:
```sh
# /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
```bash
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.
```bash
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 :wink:
|
