If we want to create a great package, we need to follow several rules. Some others may not have been saved. The following are principles which should form the package. You may ask why the name of the file creating a package that is important. Therefore, that tells us much about the package. At first glance, the name of the file we can read what the program is complex, its name and version, the version to compile and who made it. In dealing with this as different fields, we have: the name, the version field, the field of architecture and construction. Thus, the package presented in the form of: (field name) - (box version) - (the architecture) - (the building) (signature of the designer). Tgz

apache-1.2.1-i486-1jim.tgz

In the above example we see that this is a web server called Apache (field names) and is version 1.2.1 (the version). We see also that it was built for the Intel platform 386 (the architecture), where the options for this field may be:
386
i486
i586
i686
x86_64
noarch (this means that the platform has not been defined)
PPC

Due to the fact that so far there is no platform or any other SPARC is supported by Slackware, so you only need these. You should also avoid using "-" (a hyphen) in the version, because it makes updating packages very difficult and causes difficulties package managers to identify the package version. It should be borne in mind that the Slackware package manager reads from right to left and is based on the "-" (a hyphen) separating the fields.

Then a version of the construction (the building). Typically, it describes how many times the package was built. This helps managers distinguish packages, programs with different (often subsequent) versions of the compilation / configuration. In the example above, if the building would be equal to 2, that could mean that some amendments have been attached since the previous version release (1) and is an upgrade to this package (update). Also adding to the field construction of three letters, which is signed by the author (in this case is to "Jim") is a valid tool to download packages, which can thus be distinguished from non-official packages. This helps the user to determine if the package is official or not.

2. Place of installation:
This is the minimum you need to have.

. / (Without this package does not uninstall correctly)
/ install
/ install / slack-desc
/ install / slack-required (optional, as described below)
/ install / slack-conflicts (optional, as described below)
/ install / slack-suggests (optional, as described below)
/ usr / doc / package-version /

Of course, you will also have directories that will be installed by the package. The directory "doc", copy the license, as well as other important documents such as a README file, etc. described below, where most of the files should be installed:

/ etc

This location is primarily intended for configuration files. The option - sysconfdir = / etc configure command ensures us that the package will contain configuration files in this location. If you just run. / Configure - prefix = / usr if the package is likely to have the configuration files in / usr / etc / What we do not want to. Sometimes you want to put configuration files in subdirectories of the directory / etc. Such solutions are often used when the packages at the GTK and GNOME. For example: / etc / mój_program.

/ usr

This is the core of the system and most of the binary should be installed here. In most cases, using prefix = / usr expected effect and will install the program in this directory.

/ var

Var directory space is reserved for files such as logs, the numbers of processes in the system (PID), etc. This is the place for the files saved by the program. Configure command option in this case are: - localstatedir = / var.

Now you can attach to ask why so much attention to this, where the package and help files will be installed. It may be many reasons, but one of the key is standardization. Another good example is the fact that you want to run the system fully mounted as read-only. If you follow this standard, you will be able to do this very easily. Just need to mount some locations in the read / write mode and kernel-mode read-only. We want to provide a standardized package, and sometimes it takes a little work beyond the standard issue the command: make install. In conclusion - if you pass all options to properly configure and you'll use something like checkinstall to build a good package to 99%.