Getting to know Slackware packaging tools

There are two types of package tools; menu based tools and command line based tools. There is actually only one menu based tool and that’s “pkgtool” all the rest are command line tools.

You use pkgtool to get an overview of what’s installed on your system. It provides menu options to view installed packages, the content of individual packages and you can also remove currently installed packages by using the menus and you can install new ones. If you use pkgtool to install packages, you can specify a directory containing one or more packages and you will be asked a ‘yes’ or ‘no’ question about if you want them installed. If you select to remove packages you will get a list of all currently installed packages and you can then select one or more to remove.

All of the above functions can also be accomplished by using the command line tools. If, for example, you just need to install a single package, it may seem a bit tedious to have to go through a lot of menus. That’s why we have the command line tools. Here’s a description of each of them and how I mostly use them.

installpkg

Description:

installpkg is used to install a prebuilt slackware package. Basically what it does is to unzip and untar the package in the “/” (root) directory of your filesystem, and subsequently it executes the script “install/doinst.sh” from the package if it’s included (try to unpack a package from your slackware CD into a new directory and take a look at it).

How I use installpkg:

In almost all cases all I do is type a command like “installpkg packagename.tgz” (or “installpkg packagename.tar.gz”). In a few cases I may wish to review the content of a package before I install it, so I issue a command like “installpkg -warn packagename.tgz > package.log”. That gives me a file called package.log with information about what files will be installed and where; and I can now judge if I wish to install the package (if you omit the “> package.log” part the report will be dumped to your console). I rarely use the “-r” an “-m” options, they can be used to generate and/or install a subdirectory as a package, but I prefer to use makepkg for that.

[Notes on Installing more than one package. Let's say you have the kde1 dir and you want to install everything, you can cd into the kde1 dir and "installpkg *.tgz". Or you can "installpkg pack1.tgz pack2.tgz pack3.tgz"]

explodepkg
Description:

explodepkg is used to extract a package into the current directory without running the “install/doinst.sh” script from the package and without updating the installed-packages database in “/var/adm/packages”. [note that /var/adm is a sym link to /var/log, so /var/log/packages is also correct] It’s a useful tool if you are maintaining/updating a package (probably one of your own) and want to change a few things. After using explodepkg and editing the package it is a simple matter to run makepkg to recreate the package with the new and/or updated content.

How I use explodepkg:

There is only one way to use this tool; cd to an empty directory and type “explodepkg packagename.tgz”.

removepkg
Description:

removepkg is used to remove a currently installed Slackware package. It will look in “/var/adm/packages” for information about what files to remove (the entry under /var/adm/packages was created when the package was installed).

Upgrading KDE 1.1.2 to KDE 2.0.1 on Slackware Linux 7.1

Since the release of KDE 2.0.0 a lot of people have asked me to help them upgrade their existing Slackware based boxes from KDE 1.1.2 (which ships with Slackware 7.1) to KDE 2.0.1 that can be found in the slackware-current tree. So instead of answering the same question over and over, I decided to write this article, and describe the entire procedure in detail. I hope you’ll enjoy reading it and that it will be of use to anyone wanting to upgrade to KDE 2.

First of all you should be aware that the packages you need to install come from the slackware-current tree, and since that is the development tree things may not be completely in sync with your installed system. Usually the procedure I describe below works fine, but as the files in -current change quite often you may experience problems if your installed system is a lot older that the stock 7.1.

Since KDE 2 depends on very recent versions of some other libraries, these will need to be upgraded as well and a few new ones will need to be installed. This is not a difficult procedure, but it can lead to big problems if done incorrectly, so please follow the instructions carefully. The libraries in question are; glibc, qt and openssl.

Ok, let’s get on with it.
Read it all through once before making any changes (just to make sure you know what steps are involved), then start at the top again and do everything in the order shown.

And remember, BACKUP ANY IMPORTANT DATA NOW! An upgrade involves overwriting old files with new ones, installing completely new files and deleting some existing files completely. If there should happen to be errors in some of the packages or something fails or something unforeseen happens, then you could loose data. It is always a good idea to have recent backups before performing an operation such as this one. Make those backups NOW – you have been warned

First of all make sure you have all the needed files before we begin.

Start by making a directory called /updates and then make sure you have all of the following files in that directory (these should all be downloaded from the slackware-current tree from the slackware ftp server, I have shown what subdirectory the packages can be found in):

[Note: The following instructions to update KDE will also update Glibc to 2.2, I suggest you read and follow David Cantrell's instructions on upgrading to glibc 2.2 then continue reading here. -keskoy]

glibcso.tgz (slakware/a1/) !
glibc.tgz (slakware/d1/) !
qt2.tgz (slakware/kde1/) !
mesa.tgz (slakware/x1/) !
openssl.tgz (slakware/n1/) !
ksupport.tgz (slakware/kde1/) !
kdelibs.tgz (slakware/kde1/) !
kdebase.tgz (slakware/kde1/) !
kdeutils.tgz (slakware/kde1/) *
kadmin.tgz (slakware/kde1/) *
htdig.tgz (slakware/kde1/) *
kdoc.tgz (slakware/kde1/) *
kde-i18n.tgz (slakware/kde1/) -
kdegames.tgz (slakware/kde1/) -
kdepim.tgz (slakware/kde1/) -
kdetoys.tgz (slakware/kde1/) -
kgraphic.tgz (slakware/kde1/) -
kmedia.tgz (slakware/kde1/) -
knetwork.tgz (slakware/kde1/) -
koffice.tgz (slakware/kde1/) -

You will notice that I have marked the packages with 3 different symbols (!, * and -). Packages marked with ‘!’” are packages that you MUST HAVE, we cannot do this if you do not have those. Packages marked with ‘*’” are those that I consider very nice to have but not absolutely essential. And the ones marked with ‘-’ are the ones I consider to be optional.
If you don’t know very much about what are in the packages and want to make sure you have a complete KDE 2 desktop (and you have enough diskspace) then install everything – at least install the packages marked ‘!’” and ‘*’.

For the purpose of this guide, make sure that the /updates directory contain ONLY the files shown above. This is important for some of the commands that I run at the very end of the guide.

Secondly, we are about to update some central system libraries and your graphical user interface, so you should not be running said user interface while we do this. In other words; exit from KDE completely and use a plain textmode commandline to do ALL of the following. If your system boots directly into X then change that to have it boot to a textmode console (you can change it back when we are done).
To make sure that you boot to a text console and not X, use a text editor (as the root user) to edit the file ‘/etc/inittab’ and find the lines that looks like this:

# Default runlevel. (Do not set to 0 or 6)
id:4:initdefault:

These lines are close to the top of the file. The number in the second line is the important one – if it is set to 4 (as in my example) then your machine boots into X by default, and if it is 3 then you boot to a text mode console and type startx to start the GUI (this is what we want for now). Change the number to be 3 (or leave it like that if it is already 3) save the file, and reboot your machine. It is possible to do the entire upgrade without rebooting, but it will make it a bit more complicated so I will not describe that.

When your machine boots up it should present you with a plain text login prompt. Log in as the root user (the administrator).
We are now ready to start the real upgrade process. This is where the fun starts

Creating (High Optimized) KDE 2.2.2 packages from sources

In this document you will find out how tweak KDE 2.2.2 to the max, optimize it for your machine and make nice packages out of it. If you are not interested in tweaking KDE you can easily skip the tuning part, and just read how to configure, compile and make Slackware packages with KDE 2.2.2.

I will also provide all the necessary scripts for you, so compiling KDE and making packages will be really easy.

The default (shipped with Slackware 8.0) packaging tools are used (v1.1), because as reported on Slackware’s Forum the new tools (which can be found under current-tree) are little buggy yet.
When they become bugs free I will update the scripts to reflect the newer version.

General note on making packages
So you have compiled some application with your favorite settings and you would like to make a package out of it?
It’s not a difficult task in general but there are some issues you should be aware of.
The main problem with packages is that not all applications will easily install into different location than the –prefix set during configure. However there are a few methods to do this automatically with ‘make install’, and also a few to do it manually. Personally I prefer the first method :>

The trick is to run make install with a variable which will tell make where to install the application. The variable could be one of the following: prefix, PREFIX or DESTDIR. These in most cases are sufficient, however there are some applications (e.g. Lilo) which use different variable names (Lilo uses ROOT). There are also others like: execprefix, INSTALLDIR, INSTALLROOT (or installdir, install_root), ROOTDIR, etc.

So how to discover such situations? Simply run ‘make install’ with the -n switch. This will not install the application it will just print the output of the scripts to the screen, so you can see if the given variable is working.

# make -n prefix=/tmp/package-name/usr/local install

or

# make -n DESTDIR=/tmp/package-name install

…

Usually the prefix works, if it doesn’t try DESTDIR. If this also will not work try PREFIX. If all the methods (prefixes) fail look into the Makefile and see what the variable name of installation’s prefix is.

Note: As you’ve probably noticed, when prefix is used with make, you must append prefix used during configure (eg. ./configure –prefix=/usr/local), this is not required or even you must not do it when using DESTDIR.

But do not rely on prefix or DESTDIR (and others prefixes) in 100%. There are some applications, which will properly install into given ‘prefixed location’ but not all of their components will be installed there as expected. For example: freetype-1.3 is such application. Its binaries, include files and libraries are installed in the prefix we set, but the locale files go directly into your /usr/share/locale directory.
To fix it (in case of freetype-1.3) pass –with-locale-dir=/tmp/package/usr during configure. If some applications do not provide that easy method of resolving such situations, you can always edit the install-sh or configure scripts on your own or just copy the files after installation to your package directory, make a package out of it and install.
Freetype-1.3 and its locales are just an example to give you a view on problems you could meet during making packages.

My general advice is to check all configure options and run for the first time make -n install (with given prefix) and see what it will display (if you’ve never installed given application and you don’t know its ‘hidden tricks’).

Now, if you have everything into your package directory, the rest is easy. You just use makepkg, to make your own package and installpkg to install it.

# cd /tmp/package-name

# makepkg package-name.tgz

I will not describe here how to use packaging tools shipped with Slackware.
If you would like to know more about making packages you should read the tutorial “Getting to know Slackware packaging tools” written by Jesper Juhl, which describes in detail how to use it.

But let’s get back to KDE now, which installs perfectly with DESTDIR.