Print
PDF

The perfect package Updated To build the perfect package we need for follow a few rules. Some written and some not. Below we will go over some of the rules in hopes that you will follow them in creating your package. File Name Install locations Permissions and ownerships The slack-desc file Documents Misc Optional things File Name Well you might ask why is the file name so important. Well it tells alot about the package. First from the file name we can see what it was built for, the name and version of the program, the version of the build and who built it. Consider it like fields in a form. You have the name field, version field, arch field, and build field. apache-1.2.1-i386-2jim.tgz In the above example we see first that this is apache (name field) and that the version is 1.2.1 (version field). We can also see that it was built for an intel 386 platform (arch field). Valid options for this are: i386 i486 i586 i686 x86_64 noarch (means its not platform specific) PPC Since there is no sparc or any other supported platforms for slack you will only need these. Also avoid using - in the version field this makes upgrades very hard since the package manager will have issues trying to determin the version of the package. Keep in mind that the pkgmgr in Slackware reads from right to left and keys on the - parts of the file. The next part is the build version (build field). Usually means how many times it was built this helps the Slackware package manager know that a program that has the same version number is still different. In the case above, it is build 2. This could indicate a fix or something has occured since -1 was released and this is an update. Also added to the -1 is the 3 letters the author uses to distinguish himself. In this case it is jim. This is kind of important for some of the package download tools out there and helps you see an offical package from a unofficial package. It also helps the user know with the package manager what is official and what is not. Consider it your way of branding the package. Install locations I am not going to cover the install locations again you can see those in the howto area. Simply put, you must have at a minimum the following  ./ (without this the package wont remove correctly)  /install  /install/slack-desc  /install/slack-required (this is optional see below)  /install/slack-conflicts (this is optional see below)  /install/slack-suggests (this is optional see below)  /usr/doc/package-version/ Of course you will also have the directories the package installs to. In the doc directory place a copy of the License and any other good docs such as the README etc. Below are where most files should go with a brief description of the area and its purpose.  /etc This area is for configuration files mainly. The configure command --sysconfdir=/etc is used to ensure your package if it has config files places them in there. If you simply run ./configure --prefix=/usr and the package has config files they will most of the time end up in /usr/etc/ we really don't want this. Sometimes you may even want the config files placed in a subdirectory in etc. If you look gtk and gnome packages sometimes do this. Example /etc/myrogramr.  /usr This is the core of the sytem and were most binaries should be installed to. In most cases using prefix=/usr will get the effect you need to get the program installed in there.  /var The var area is for files, logs, pids etc.. This area is for files that get written to by the program. The configure prefix for this is ./configure --localstatedir=DIR. Now you may ask why all this care about where packages and the support files get installed. This has many reasons but the main one is standardization. Another good example is say I want to have a running system that is almost entirely mounted readonly. If I follow the standards I can do this very easy. I simply need to mount certain areas rw and the core of the system ro. We really want to provide a standard package for people and sometimes it takes a little work besides the standard make install. Again if you pass all the correct arguments to configure and use something like checkinstall you will end up with a good package 99 % of the time. Permissions and Ownerships For a good package you must have the correct permissions. This includes the file mode and user and group ownerships of the file. Certain areas in the file system have special group access rights that need to be followed. In general directories should be 0755 (drwxr-xr-x). Different file types will have different permissions. A good rule to follow is if it is a file that must be read use 0644 (-rw-r--r--) documents icons and other type support files are a good example. Executables should be 0755(-rwxr-xr-x). This is just a general rule and may not be true all of the time. Most files in the package will be user root group root. The exception to this rule is the bin areas. All files and directories in these areas should be user root group bin. Now as of Slackware 11.0 this area will be root.root. So if you are building for 11.0 use root.root for everything, but if you are building for 10.2 and below you should still use root.bin. Below is a brief list of those areas: /usr/bin /bin /sbin /usr/sbin /usr/X11R6/bin Permissions and ownership are another important part of a package. Taking the time to ensure these are correct will result in a perfect package. Slack-Desc The slack-desc file is very important since it helps keep the package database updated with good information for you to see. It also helps some tools identify the package. For an explination of the format see this page. The Slack-desc file. We also have an automated slack-desc tool here that will help you create that perfect slack-desc file. Documents Almost every type of license out there requires that the license always go with the program. That is why we require a /usr/doc/package directory. It is afterall mostly free software and has only a few rules we need to follow. Also this directory should contain some information about how to use the program if any came with it. Its also a good place for sample config files should the program use them. Documents can also be in /usr/share/doc/package since this is a symlink to /usr/doc. Some programs install them here automatcially and that is acceptable. Misc There are some things that will help you out in the long run and help you make that perfect package. One important issue that is coming up more and more these day is compile options. Don't compile with i686 optimization we want the package to be used by everyone and not everyone has a i686. The default for now is i486 for Slackware. Also just because you are building on a i686 that doesn't mean your package is optimized for i686. You have to manually tell gcc to optimize the compile. Many people get confused with this. One final note on this, in most cases you will not see a human noticable difference between i486 and i686. In fact there is tons of evidence on the net right now that shows in some cases it may slow the application down. Now for that perfect package follow the guides listed above. After you create the package use the tar command to look it over and make sure at least the perms and structor are correct, something like tar tfvz thepackage.tgz. Then take some extra time to do the following: gzip those man pages gzip info pages, remove the /usr/info/dir file if it is there. This is the main index file for the info system and you should not replace it. If you want to add to it see the doinst howto on this site for instructions on using the info system to add the new info file. strip binaries and libraries (from the root before you run makepkg run these commands) find . | xargs file | grep "current ar archive" | cut -f 1 -d : | xargs strip --str ip-debug find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded check permissions and ownerships Optional things First these again are optional, however we have written our backend to parse these files so that the user can see more information about a package. This was the most logical choice since we cannot run and ldd on every package to show this vital information. There are two major tools out there, both support dependency checking. Swaret supports it with an internal checker that uses a master file on the swaret web site. Swaret does not require any special modifications to the package to suport this. However if you would like your package to be used by all tools and our backend you must make a small modification to your package. It is not a bad idea to list dependencies in the slack-desc file and on the website when you submit the package also. You can include additional files in your /install directory called slack-required, slack-conflicts, slack-suggests. You really only need to use this if you have some type of library or application that is not installed on a standard slack system. However if the application or library is not standard or is of a higher version then it should be listed. This is a clean approach to dependencies since not only are libraries considered a dependency in many cases applications can also be a dependency that would not return a standard missing library error. Another file you can include is the slack-conflicts, this file is used to list packages that will conflict with other packages. For instance mozilla and firefox depending on how you install it they can conflict with each other by overwriting vital libraries. The last file you can add is the slack-suggests, this file simply lists optional packages that may work with a program. For instance evolution although doesn't require gnome-spell if it is on the system it will use it and add spell checking to the applications. You will notice that this is more like a debian approach to packages. We do not want to modify the tools that are included in Slackware so we have to work around these things. Using these optional support files allows us to do that. slack-required: The structure of this file is one entry per line in the following format: package_name or [package_name] [condition] [version] where [condition] is =, >=, =<, <, or > <= and =< should both work, just in case of editing errors. example man >= 1.5l-i386-1 Notice that we have included the version arch and build number this will help with version checking. Don't worry the condition statement takes care of things if there is a newer version available. slack-conflicts: The format of this file is just simply the same as the slack-required file. Follow the above format for this file. slack-suggests: The format of this file is simply the program name nothing more: gnome-spell You the creator should know more than anyone what your package requires. And remember that you should build on a clean slackware install do not use -current, dropline gnome or your packages will surely fail on a release version. unless you are sure about what your package is going to require. After receiving emails about the build scripts we decided to add this part. Since at this time there is no standard location for these we have asked many in the community and came up with install build script to /usr/src/slackbuilds. If you have a build script that you use to create your package include it in the package. The location to place the file is /usr/src/slackbuilds/packagename. Since these are generally small it will not increase the size of your package and will make the package complete and perfect. Well thats about it for the perfect package. Drop me a line if you think we should add anything to this.