Package management on Linux systems has always been the subject of endless discussions, flamefests and bickering. Nonetheless, regardless of what one prefers, there’s something for everyone, if not in distro X, then maybe in distro Y. Some swear by binary package management, others say that the only true way is compilation from source. Today we will focus on two distributions that offer the best of both worlds : Arch Linux and Slackware.
Introduction
Before we delve into package management on Arch and Slackware, we will explain some generalities about Linux package management, so you will have a little theoretical and historical background. In the old days, people used to compile software from source and liked it. Then, as software grew more complex, software compilation became tedious and time-consuming, as dependencies became more and more of a problem. This is how package management appeared, in order to ease user’s installation tasks. From a certain point of view, there are two types of package management : binary and source. Binary means that software is already compiled and a package is basically an archive that the package manager unpacks on your system, making lots of software available in a snap. This is quick and painless usually, however, there are some drawbacks : you might get software installed as a dependency that you’ll never use, and even the software you installed might never use it, it’s just installed because the distribution has a philosophy of “everything and the kitchen sink”. Plus you can’t control the compile-time options of what you install, since the program/library is already compiled. Even so, this is the most popular way of installing software on Linux systems, because it’s fuss-free and fast.
Distributions that want to address those problems usually take two directions : the opposite, as in compile everything from source (like Gentoo), which offers a great degree of customization and speed, since the software is compiled ON your system FOR your system, but that tends to be a lot “geekier” and time-consuming, especially when dealing with big software installations, or offer a mixed packaging environment : offer some basic packages as binaries, with (Arch) or without (Slackware) dependency checking, and offering the rest as source with a compilation script, so you can roll your own packages. This offers the best of both worlds, and of course, you can recompile the base packages to your liking, nobody’s stopping you.
We want to warn you that this article will only deal with using AUR and slackbuilds. We assume that you have Arch and/or Slackware up and running, since we will not deal with installing those systems.So, let’s get to work.
Arch Linux and AUR
One of the many things Arch and Slackware have in common is good documentation. We use both distributions for some years and never had a problem that did not get solved by using the Arch wiki, Slackbook or IRC channels. We will try to be as complete as possible, but should you encounter a problem, feel free to profit from free and quality knowledge.
So, you want to install an application and can’t find it in the Arch repositories. No need to panic, chances are you’ll find a build script in AUR, which stands for Arch User Repository. As you can see, you are invited to read the guidelines in order to get familiar with what AUR is and what makes it tick. Before you start searching the AUR website for the package of your desire, make certain you have everything you need.First, install base-devel so you have the necessary tools to build software, then create somewhere in your home a directory to be used only for AUR builds. Thus you ensure order on your file system and make your life easier later. Besides reading the aforementioned web page, we also suggest reading the page about /etc/makepkg.conf in order to customize some build-related variables to fit your system.
After preparing, you are ready for your first custom package. We chose, for the sake of example, mksh (The MirBSD ksh-clone). We found it after searching for ‘mksh’ and went to its’ AUR page. After downloading the tarball in our AUR-specific folder, we see a file named ‘mksh.tar.gz’ in there. After unpacking it and changing into the newly created mksh directory, we see two files : mksh.install and PKGBUILD. Take some time here to open these files with your editor of choice and try to understand what they do. If you read our article about custom Fedora packages, you will probably notice some similarities. mksh.install is a small script that takes care of post-install issues and the PKGBUILD, the essence of the matter, does just what a spec file does : package version, description, dependencies, build commands, etc. Yes, as opposed to slackbuilds, as we will see, PKGBUILDs take care of possible dependencies.
But enough talk, let’s get to building mksh. As usual, building MUST be done as user, and only installation must be done as root.
$ makepkg
in the mksh folder will take care of building. On my system I get an error because cpio is a dependency (mksh is archived as cpio). Adding the -s flag to makepkg installs cpio after asking for my admin password, then proceeds with building mksh. So the -s flag to makepkg takes care of dependency problems, remember to use it when needed. Building won’t take long, since mksh isn’t a big package, and you will find a .tar.xz archive in your current directory. That you will install with
# pacman -U mksh-R40b-1-x86_64.pkg.tar.xz
and you’re done. This is, in our opinion, an efficient way to install software customized the way you like it on your Arch systems. This also goes well with the distro’s philosophy of keeping it simple and appealing to DYI people. You can, of course, modify the source and the compile flags as you see fit, and you can and should keep up to date with new package versions by subscribing to that package’s news feed. The sky’s the limit.
Slackbuilds
Slackbuilds, just like the packages in AUR, are basically user-submitted scripts to address one’s need for a package not to be found in the official repos. Slackware has a policy of one application per task, so no wonder its official sources have less packages compared to, say, Debian or OpenSUSE. Here’s where slackbuilds come to help : you go to the web page, search for the package you need, download that , build and install. The HOWTO helps you get started and you will notice some similarities between Arch and Slackware in this respect. Before we go on, it’s better you should know that you have two ways to get the desired slackbuilds : one is by individually downloading the needed slackbuild from the web page, the other is cloning the entire slackbuilds repository somewhere in your home folder and work from there, most like ports/pkgsrc in BSD systems. We prefer the cloning variant, so this is how we will work in our example. You can get hold of the slackbuilds repository by ftp, git, cgit, rsync and http, but we will use git, because it’s easy to stay current with the latest updates (sometimes the slackbuilds on the webpage can be a little outdated). If you don’t have git installed, you can get it with
# slackpkg install git
and then, in your home directory
$ git clone git://slackbuilds.org/slackbuilds
This will create a directory called ‘slackbuilds’ and clone all the repository there. If you want a different name for the directory, use it as an argument :
$ git clone git://slackbuilds.org/slackbuilds mycustomdirectory
Whatever the name, you now have all the slackbuilds handy on your hard drive. Later, you will want to update to the latest and greatest. Change to the directory and just do
$ git pull
to update it.
So, now that we’re set (of course we presume that you already have gcc, make and friends installed), let’s install mksh. We use
$ cd slackbuilds && find . -name mksh -print
to find that what we’re looking for is in the system/mksh directory. Just as in Arch the key file is PKGBUILD, here the key file is mksh.SlackBuild, that is, generically speaking, $packagename.SlackBuild. Take your time and look through the file and you will find there are some similarities between it and a PKGBUILD file. You can customize almost every aspect, you can change the version if you want a different one, change the destination directories and so on.
When you’re done reading/customizing, make the .SlackBuild file executable and run it :
$ chmod +x mksh.SlackBuild # ./mksh.SlackBuild
and you will get a file not found error. Slackware isn’t as user-friendly as Arch : dig into the mksh.info file (which you’ll have to modify if you want to get another version) and you will see a line like
DOWNLOAD="http://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R40b.cpio.gz"
which you’ll use to download the source archive in the current (work) directory :
$ wget -c http://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R40b.cpio.gz
Now try again running the script (as root, as seen above). If everything goes well, you will see a line like “Slackware package /tmp/mksh-R40b-i486-1_SBo.tgz created.”. Now that the package is created, all you have to do is install it :
# installpkg /tmp/mksh-R40b-i486-1_SBo.tgz
Simple, is it now? We recommend you create a directory with all your created packages since you can re-use them sometime, maybe on another machines, and create a local repository. That, and the fact that /tmp/ is a “volatile” location, makes this a recommended practice.
In the end of our little HOWTO, we recommend two resources from the Slackware Wiki that will help you get better at working with slackbuilds and even create some yourself : the first is about installing from slackbuilds and the other is about writing your own. We only hope you enjoy working with these two distros and wish you good luck and happy hacking.
