[SLACKWARE] Package Creation how-to

[kemical]

Cant find a Slackware package you are looking for? Make your own! :)

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. 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 

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 FHB. 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. Once you have the program compiled well will pass it another prefix to actually put it in our build area. 

make install prefix=/work/builds/usr 

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. 

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. 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. 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.linuxmafia.org

source : http://www.linuxpackages.net/howto.php?pag...e=Package+Howto

Make sure to include a slack-desc as well in your package so people know what they are installing, place in your isntall directory to use the slack-desc file

source : http://www.linuxpackages.net/slackcreator.php

Note: I created a package for Pigeon 0.4.1 which is a Gnome/GTK+ cd burner app by following these tutorials, worked rather well and without a hitch.

[kemical]

since i haven't used slack that long i keep finding nifty little utilities that help you along the way this one falls along the line of creating packages per system based..

when compiling from source

./configure

make

checkinstall -S

it will walk you through a couple of steps of adding a description to the package etc. works pretty good ;)