Print
PDF

Building a Slackware Package Updated 25 April 04 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 the slackware ftp site or its mirrors. You may also want to look at the tools section there are some good tools to help you build the perfect package. Check the howto area for information. Special Attentions Items: 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 and also if I need to send conf file or pid files to another location. 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: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var 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 FHS. 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 Slackware 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. Here are a few extra steps you may want to take to ensure permissions are correct before you issue start the build process.  These will just fix bad perms in the source so when you copy the files such as docs and such into your build are the perms are already set. chown -R root.root . find . -perm 777 -exec chmod 755 {} \; find . -perm 555 -exec chmod 755 {} \; find . -perm 444 -exec chmod 644 {} \; find . -perm 666 -exec chmod 644 {} \; find . -perm 664 -exec chmod 644 {} \; Once you have the program compiled we will pass it another arg to actually put it in our build area.  With newer programs you have a few options.  The best is to use the DESTDIR= but not all makefiles honor this.  The three possible things I have seen are DESTDIR=/work/builds ROOT=/work/builds or prefix=/work/builds/usr make install DESTDIR=/work/builds 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. There are a couple of other files that will go in the /install directory of the package. These are the doinst.sh file and slack-desc file. Not all packages will have a doinst.sh file. The doinst.sh will also be created by makepkg if you have symlinks in your package. It is optional to remove the links but a good idea. If you have anything with special needs to be done post install the doinst.sh is the file for these commands For some tips and detailed information on using the doinst.sh file see our help page titled doinst file. All package must have a slack-desc since this file will populate the package manager system with information about that package. For information about the slack-desc file see our help page titled the slack-desc file. Ok now that we have the package all tidy in /work/builds lets go ahead and make it. One mistake most folks make is not ensuring the build folder is owned by root and has the correct perms.  Remember this will be the root of the file system the package is installed on.  The best thing is to type chown root.root . and chmod 755 . from inside the /work/builds directory.  Next type "makepkg name-version-arch-build.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. The only problem with this though is that /usr/bin is suppost to be owned by the group bin as are the files included in there.  If you say yes those permissions will be changed.  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 can also take a look at the inside of your package with something like tar tzvf program-verison-i486-1.tgz this will show you the files, ownerships, and permissions of the files inside. Filenames 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. You must use the standard naming convention. The format is application-version-i386-1xxx.tgz For more information see building the perfect package here Dependencies Again as stated before be sure that if a package requires libraries that are not part of a standard Slackware 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 unless it is a library that only that program uses. If a package requires a library that is not a standard install in Slackware 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 Slackware is about the best resource for learning this. You can also use our build script archive which is based on slackware build scripts with a few modifications.  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. TG tg.nospam@nospam.linuxpackages.net