Tutorial Section

Slackware Package Creation - quick and dirty

Author: TG Slackware Release: Slackware 7.0 and higher Written on: 2002-08-08

From linuxpackages.net comes with a special permission of TG the ultimative package building HOWTO:

This HOWTO is aimed at trying to help users build packages for Slackware. It is just a rough guide and is not an all inclusive howto. To start we need to make some rules for our packages. The first is that since we are building them for others we need to pay special attention to the build. This howto shows the quick and dirty way build scripts are always the better route to take if possible. You can always go see them, most are called "program".build or Slackbuild in the source area on cdrom.com or its mirrors.

• Permissions
• Dependencies
• Installation Location

We will cover each in detail later on. For now lets see how to make one.

First step is to make a clean work area. In this work area I have a place that I do all the compiles and also a directory that I do all the installs to. For instance I have a directory called work and inside that one I have two directories one I keep my build scripts if I make them and also one for the actual install. My setup is like this:

/work (my work area)
/work/scripts (where I keep my scripts to make it easy to upgrade them if needed)
/work/builds (where I try and install the program to)

I keep my scripts for several reasons, one for easy upgrade of a package should I need to build a new version and so that I can distribute them with my package. You need to be consistent with the package, for example it must be installed the exact same way as you did the first time so that upgradepkg will work with it and it will not break any other programs.

Lets go through a sample build:

The first step is of course get the program and unarchive it to your work area. tar xfz whatever.tar.gz. Then next step is of course to cd into the directory and check out how its configure script works. I generally do a ./configure --help and check out all the options. This helps me determine if something needs to be turned on by configure or turned off. Some programs need to know the location of files or libraries and also may need things set before the compile. This is also the time when we are going to tell it where to install to. 90% of the time you will pass it something like this:

This will depend on the program of course. First we do this because if you have noticed most programs will install to /usr/local by default. We don't want this since we are going to let others use this package /usr/local is off limits basically for packages that others will be using. This is outlined in the FSB. We pass this even though we will not be installing the package there in the build process. Once we have configured it we will go ahead and compile it. Again pay attention to any requirements the program may have. If a library that it needs is not part of SL7 the package will not work for the user. Its best to do all your builds on a clean machine if possible since over time most tend to loose track of what you have installed. There are two ways to approach this problem. First is make another package that has the required library (preferred) or include the library with the package (not a good thing since it could cause problems later). Now simply type make to build the package, you need to watch the make process as well sometimes paths are hard coded into a program that may for instance have a conf file if you see it pointing to someplace besides where you told configure the prefix is you will have to go back and figure out where to change that. I have had some programs that I have had to actually change the source on just to get this to work. Once you have the program compiled well will pass it another prefix to actually put it in our build area.

This will generally work for most programs however some will not. During the make install watch very closely make sure it all went to /work/builds/usr and not to your /usr sometimes some of it will go to one location and some to the /usr. Once you have done this make a quick sweep of your actual / to see if it did in fact put files in the /usr instead of /work/builds/usr I generally do this by going around and checking file dates. If you find files that went to /usr simply move them over to /work/builds/usr make sure its the same location you found them in /usr. Once this is done we need to make the doc area to copy the documents to. This will always be /work/builds/usr/doc you will need to create this the first time and will also need to create a directory there with the program name and version take a look at your own /usr/doc for a guide. Copy and documents from the source of the program there make sure to include the GPL and any readme's the program may have.

Another nice program to use for watching an install is installwatch, available in the package central area on this site. There are two version if you plan to distribute your packages do not use the one that makes the package for you it will miss doing all the docs etc. Installwatch will log every file that is installed to a file so you can go back and double check that everything was installed where you told it to. Its also a good tool to use when make install prefix doesn't work. Very common with any KDE type programs. Once you know where things are installed you can just copy what is needed into your build area. Caution when doing this though watch those permissions and ownerships.

Ok now that we have the package all tidy in /work/builds lets go ahead and make it. From inside the /work/builds directory type "makepkg name.tgz" this will create a package based on what is in that directory. Pay attention to symlinks if any are there make sure they are set correctly and not pointing to / work/builds/usr. When asked if you want to remove them and let the install program recreate them choose yes. Also when asked about changing owner and group permissions choose yes unless you have checked them and are happy with how they are. After it builds you will end up with the package. The best way to test it is to install it with pkgtool. If it works great you have now created your first package and are ready to share it with the rest of the world.

You need to be consistent with your filenames. This helps the user use upgradepkg on your packages should you build a new version. If not you can end up with stray junk all over the place since most will not remove the old before installing the new. Which in some cases you would not want to, due to conf files. Try and stick to the old dos limit of 8 and don't put the version in the file name. Example BitchX-1.1.tgz would not be good where bitchx.tgz would. Another point is that if the package is an upgrade to what is shipped with SL7 go to the source director on cdrom.com or a mirror and get the build script used originally. This will keep consistency with the default packages as well as yours. There is a small draw back to this on the big packages such as tcp1 or 2 that contain many programs.

Again as stated before be sure that if a package requires libraries that are not part of a standard SL7 install you either create a new package with just those libraries or include them in the package. Creating a new package of the libraries is the best option. If a package requires a library that is not a standard install in SL7 but is an option make sure you put that and any other information in a readme file and put it with your package where ever you put it for download. Also where ever you put your package you need to put the source remember the GPL. Also check your program make sure its legal to do what you are doing with it. Finally email the authors let them know what you have done and where your package is. In closing the best way to get started is to just jump in. The build scripts in the source area for SL7 is about the best resource for learning this. Go look to see how they built packages for the default install. Remember test test test is always the best option find a friend to be your guinea pig, we do not want to end up like the RPM world has, if you have noticed RPM's just don't work allot of the time due to no standards being followed by the creators.

You can change the language of the article by choosing another one out of the "Select Language"-DropDown Box. Please note that during the session of visiting the article the language in the navigation bar also changes. But it is not set for the whole site.

SlackFAQ Version 3.0, Created by Bjoern Berg
All rights reserved. All articles found on SlackFAQ are recommend to share with others without changing the content and crediting the article with the author's name. See also Notes for more details.