Build your own Slackware repository

Automated Repository Management

© Photo by freestocks on Unsplash

© Photo by freestocks on Unsplash

Article from Issue 272/2023
Author(s):

If you deploy software packages to several computers, the standard Slackware tools lack efficiency. We show you how to create a custom repository to automatically install and upgrade software for multiple systems.

Slackware [1] has a bad reputation when it comes to package management. Many new users experience Linux through distributions that include advanced package managers. Tools such as Apt or Discover [2] set expectations and, for a new user, define how a package manager functions as well as its capabilities. Modern package managers can track software dependencies, purge software no longer in use, search and find applications in the available repositories, and perform system upgrades. When users come in contact with Slackware, they find Slackware's approach too different from what they are used to and wonder why would anybody like it.

Intended to be installed as a monolithic system, you are expected to install the whole Slackware distribution on a machine. Slackware includes lots of libraries, desktop environments, web browsers and, ultimately, most software needed for a personal workstation or server. You can partially install Slackware (e.g., if you plan to run a web server, you may skip installing a graphical desktop environment), but partial installs are not officially supported.

In practical terms, what you get on the DVD is all there is to official Slackware. Unlike Apt, there are no official repositories for extra software. Official Slackware repositories exist only to serve upgrades to existing installs. The only official Slackware tool that interacts with the repositories directly, slackpkg [3], is designed specifically to fetch security updates and keep your system in sync with the official package tree.

When a Slackware administrator needs to install software not included in the official distribution, they must do so using unofficial means. Traditionally, users would build their own packages from source. Slackware packages have a simple format, and it is very easy to create packages from a project's source code using build scripts, commonly known as SlackBuild scripts. Eventually, the Slackware community created the SlackBuilds.org [4] website (Figure 1), which stores a large stockpile of build scripts that administrators may use to build any required package manually.

Figure 1: SlackBuilds.org hosts an amazing number of SlackBuild scripts that allow administrators to package applications from source code.

SlackBuild scripts still have shortcomings. In order to get a complex application installed, the user must track down the application's dependencies and get the build scripts and source code for each application. SlackBuild scripts make the process easier, but they don't automate it. To solve this, the Slackware community has developed some useful third-party tools that make use of SlackBuilds.org. Programs such as sbopkg [5] and sbotools [6] can replicate the Apt experience: If you instruct these tools to install a package, they will build, package, and install the requested program alongside its dependencies automatically. In particular, sbotools replicates using a ports system like the ones used by the BSD family of operating systems.

Unfortunately, these tools are not very helpful if you intend to manage a fleet of Slackware computers. Issuing an install command using one of these pseudo-ports systems on every computer would cause all the software to be downloaded once for each machine, and then every computer would compile and install its own packages. This is very inefficient. Instead, if you are responsible for a sizable number of Slackware machines, a custom repository allows you to compile each package just once and distribute it to an indefinite number of machines with minimal effort.

Why Bother with Slackware?

You may be wondering why you would bother using the Slackware package system. Instead of going to the trouble of using a ports system or building a custom repository, you could use a distribution such as Devuan that offers ready-made repositories.

It comes down to flexibility. With Devuan, if you use the stable version (Devuan Chimaera) and find out you need a more recent version of a library, upgrading the library might prove challenging. Just picking up the version you need from a development branch may not work, because the package manager may refuse to install it unless you bring along a whole set of dependencies. Changing a library may also cause you to break the applications that use it. While you can upgrade some isolated components in binary distributions, the process can become complex.

When you use source-based software provisioning, you are provided with an automated way of solving these conflicts out of the box. If you need to apply a patch to one of the installed programs, or upgrade it to a newer version, the only thing you need to do is to bump a number in a configuration file in your build system. The computer will build your upgraded package specifically for your environment and deploy it with (usually) no conflicts.

To learn more about other popular distributions that use a software provisioning approach, see the "Ports-Based Systems" box.

Ports-Based Systems

Ports are scripted mechanisms designed to build programs from source. The user issues a command to install a specific piece of software, and the ports system builds and installs it alongside its dependencies.

Gentoo is probably the most popular source-based Linux distribution. It makes use of a complex (if powerful) ports system. Gentoo supports flags, which let you configure Gentoo to build itself according to your specifications. With flags, you can build your distribution without components you might not want, such as PAM, PulseAudio, or systemd.

The BSD operating system family also makes use of ports. FreeBSD, OpenBSD, NetBSD, and DragonflyBSD can use either their own ports systems or regular repositories with binary packages (with some skill, a combination of both in some cases). This approach is quite powerful and offers the best of both worlds.

NetBSD's port system, pkgsrc [7], is designed to be portable and may be used on other operating systems (MINIX 3, illumos, and others) to some degree.

slackrepo

Slackrepo [8] (Figure 2), created by David Spencer and maintained by Andrew Clemons [9], offers the best way to create a custom Slackware repository.

Figure 2: Slackrepo's original homepage (shown here) has been abandoned, but the program lives on under the maintainership of Andrew Clemons.

Slackrepo is a set of tools capable of taking a set of build scripts and compiling any packages you may need distributed to your systems. You can load packages created this way onto a web server, which may be used as a formal repository.

This article provides precise instructions on how to create a custom repository with slackrepo and then configure your Slackware computers to use it. The slackrepo server will be in our LAN with the IP address 192.168.3.40 in this example, while our other Slackware machines will have arbitrary addresses in network 192.168.3.0/24.

In order to get started, you first need to install a full Slackware system on the server. Slackrepo is intended to run on a fresh install with all the official software installed. Listing 1 summarizes building slackrepo using a build script from SlackBuilds.org along with its "hintfiles," which are instructions for slackrepo to build some tricky software. Slackrepo can use fakeroot as an optional dependency, which allows it to prevent the repository building engine from interfering with the host operating system.

Listing 1

Install Slackrepo on the Server

01 # Download the SlackBuild script for fakeroot, unpack it, download fakeroot and
02 # build it using the script.
03
04 cd /tmp
05 wget https://slackbuilds.org/slackbuilds/15.0/system/fakeroot.tar.gz
06 tar -xzf fakeroot.tar.gz
07 cd fakeroot
08 wget http://ponce.cc/slackware/sources/repo/fakeroot_1.25.3.orig.tar.gz
09 bash ./fakeroot.SlackBuild
10 installpkg /tmp/fakeroot*.tgz
11
12 # Download the SlackBuild script for slackrepo, unpack it, download slackrepo and
13 # build it using the script.
14
15 cd /tmp
16 wget https://slackbuilds.org/slackbuilds/15.0/system/slackrepo.tar.gz
17 tar -xzf slackrepo.tar.gz
18 cd slackrepo
19 wget https://github.com/aclemons/slackrepo/archive/v20230107/slackrepo-20230107.tar.gz
20 bash ./slackrepo.SlackBuild
21 installpkg /tmp/slackrepo*.tgz
22
23 # Download the SlackBuild script for the hintfiles, unpack it, download the hintfiles and
24 # build them using the script.
25
26 cd /tmp
27 wget https://slackbuilds.org/slackbuilds/15.0/system/slackrepo-hints.tar.gz
28 tar -xzf slackrepo-hints.tar.gz
29 cd slackrepo-hints
30 wget https://github.com/aclemons/slackrepo-hints/archive/v20230128/slackrepo-hints-20230128.tar.gz
31 bash ./slackrepo-hints.SlackBuild
32 installpkg /tmp/slackrepo-hints*.tgz

By default, slackrepo is configured to download the whole repository of SlackBuild scripts from SlackBuilds.org, which is what most administrators will want. Slackrepo updates the local SlackBuilds tree every time it is used and if more than one day has passed since it was last executed.

In order to create a formal repository, you must create GPG keys to sign the packages. Package signatures are used by the clients to verify the integrity of the packages downloaded from your repository. Listing 2 shows you how to create signing keys on the slackrepo server and then output the file GPG-KEY, which will be distributed to the clients. Clients will use this file to validate the packages. Beware: The instructions in Listing 2 aren't particularly safe, because the OpenPGP key is left unencrypted, but I am choosing this method for the sake of clarity.

Listing 2

Creating Keys for Package Signatures

01 gpg2 --batch --yes --passphrase="" --quick-generate-key "Repomaster <repomaster@example.org>" dsa
02 gpg2 --export -a Repomaster > GPG-KEY

You then must configure slackrepo to use this key. Edit the /etc/slackrepo/slackrepo_SBo.conf file and perform the changes shown in Listing 3.

Listing 3

slackrepo.conf Variables

01 USE_GENREPOS=1
02 REPOSOWNER="Repomaster <repomaster@example.org>
03 DL_URL=http://192.168.3.40/pkgrepo/%REPO%/%SLACKVER%/%ARCH%"
04 RSS_UUID=SOME_EXAMPLE_UUID
05 GPGBIN=/usr/bin/gpg2
06 FOR_SLAPTGET="1"

To ensure your values are correct, generate a valid RSS_UUID with the command uuidgen -t.

You are now ready to start deploying your packages. As a demonstration, I'll build the Hedgewars package [10] along with its dependencies:

# slackrepo build hedgewars

A minimal repository will be placed in /var/lib/slackrepo/SBo/packages. You may compile as many additional packages as needed, and all the packages will be placed here. You may also move everything to a web server folder at this point:

# rsync --delete -as /var/lib/slackrepo/SBo/packages/ /var/www/htdocs/
# mv GPG-KEY /var/www/htdocs/15.0/x86_64/

Now, you just need to enable and launch the web server included with a Slackware full install:

# chmod +x /etc/rc.d/rc.httpd
# /etc/rc.d/rc.httpd start

You will now find your repository online at http://192.168.3.40 (as shown in Figure 3).

Figure 3: The repository built by slackrepo contains the Hedgewars packages with its dependencies. Slackrepo also supports delivering signed packages, which allow the clients to validate downloads before installation.

Client Setup

You now have a package repository, but how can you leverage it?

Packages stored in slackrepo repositories may be downloaded and installed manually, but Slackware supports a number of tools for automating the task. The previously mentioned sbopkg is a popular choice, but for this example, I am going to use slackpkg, because it is closer to the standard Slackware operational model.

While slackpkg is intended for use only with official Slackware repositories, the slackpkg+ plugin lets you work with separate repositories. You can install slackpkg+ on a given client machine as follows:

# wget https://slakfinder.org/slackpkg+/pkg/slackpkg+-1.8.0-noarch-7mt.txz
# installpkg slackpkg+-1.8.0-noarch-7mt.
txz

Next, you need to configure slackpkg+. The simplest way is to edit /etc/slackpkg/slackpkgplus.conf on each client machine and set the variables shown in Listing 4.

Listing 4

Setting Variables in slackpkgplus.conf

01 REPOPLUS=( custom )
02 MIRRORPLUS['custom']=http://192.168.3.40/15.0/x86_64/

Finally, uncomment any of the official Slackware mirrors of your choice in /etc/slackpkg/mirrors. The repository may now be used to install any package you require:

# slackpkg gpg-update
# slackpkg update
# slackpkg install physfs ghc lua fpc hedgewars

Keep in mind slackpkg does not do dependency tracking. However, when you perform your regular Slackware upgrades, any package from your custom repository that gets upgraded in the server will be picked up by slackpkg:

# slackpkg update
# slackpkg upgrade-all

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News