Here’s the official description of aaa_base:
Sets up the empty directory tree for Slackware and adds an email to root’s mailbox welcoming them to Linux. :) This package should be installed first, and never uninstalled.
To understand the contents and installation of the aaa_base package is to understand the
simplicity
of Slackware packages in general.
So let’s waste no time cracking into this thing by manually performing the simple steps of a Slackware package installation.
First, we’ll create a directory for our experiment
$ mkdir /tmp/aaa $ cd /tmp/aaa
and then download the package
$ wget https://mirrors.slackware.com/slackware/slackware64-14.2/slackware64/a/aaa_base-14.2-x86_64-2.txz
We can use tar to create a list of the contents of the package:
$ tar -tf aaa_base-14.2-x86_64-2.txz | less
Browsing the listing, we see that it’s a mere 127 directories and files:
./ bin/ run/ media/ media/memory1/ media/hd0/ media/cdrecorder0/ media/zip0/ media/cdrom0/ media/zip1/ ... usr/local/etc/ usr/doc/ usr/src/ root/ proc/ etc/ etc/X11/ etc/os-release etc/slackware-version dev/
This is a package? What’s going on here?
When packages are installed, they are decompressed and unarchived.
The tool which typically does this work is Slackware’s standard installpkg utility, which is a dense little 500 line shell script. It detects the compression type and uses tar to extract the archive.
The destination is the root directory (/).
Any directories which don’t exist will be created by tar as needed.
So in a very real sense, this package contains the entire initial Slackware filesystem!
Performing a faux install
Since I’m in a safe place for this experiment (/tmp/aaa, as mentioned above), I can "install" the package right here:
$ tar -xf aaa_base-14.2-x86_64-2.txz
Let’s see what we’ve got:
$ ls bin dev home lib media opt root sbin sys usr boot etc install lib64 mnt proc run srv tmp var
Ha! Now there’s a whole Slackware root directory structure in /tmp/aaa!
The package description also mentioned some mail, so there must be some other stuff in here.
We can use find to list the non-directory files:
$ find -type f ./media/README ./install/doinst.sh ./install/slack-desc ./mnt/README ./var/spool/mail/root.new ./etc/os-release ./etc/slackware-version
That’s just 7 files.
Of these, there are two READMEs, two information files (in /etc) and the email from Patrick Volkerding (/var/spool/mail/root.new) welcoming us to Slackware.
That leaves two files of interest in the /install directory. Wait, /install isn’t part of the Slackware root directory structure is it? No, it’s not.
The /install directory is indeed created when a package is unarchived, but it is cleaned up after the installation is complete.
Its purpose is to contain install-specific files for this package.
At the very least, it should contain a slack-desc (package description) text file.
Optionally, it may also have an installation script called doinst.sh.
The package install script
If a package needs to do any work after its files have been spread around the target filesystem, then this work will be performed by doinst.sh.
In the case of aaa_base, we do have a /install/doinst.sh script.
Why does a listing of directories and files need a script? It turns out that much of the script is used to set up symbolic links. Many (most?) of these exist to make the structure compatible with various standards and/or other Unix systems.
Here’s a typical passage from the script:
# "/var/adm" is where I used to keep the Slackware package database until # the FHS people "standardized" making it a symlink to /var/log... ( cd var ; rm -rf adm ) ( cd var ; ln -sf log adm )
I like reading these sorts of comments in Slackware’s various packages and scripts. They give me a sense of the humans behind the distro.
Also, they often tell a history of Slackware and Linux itself. For example, this script mentions a change to glibc header links starting with Slackware version 8.1, which was released in 2002.
To be continued…
I am very excited to have finally written this first entry of the pkgblog. I know better than to promise any particular kind of schedule, but I hope to be "regular" about it. Whether that ends up being daily, weekly, or monthly is anybody’s guess.
There are 1,332 packages in Slackware 14.2 by my count. Even on an almost daily schedule, that’s just under four years of entries. Keeping up with new releases of Slackware will be interesting - I’ll have to figure out what to do about that when it happens.
Until next time (which will be package aaa_elflibs), happy hacking!