Here we'll cover the basic usage of src2pkg from the command line. First, you should know that src2pkg includes 3 command-line programs for helping you to create packages. The main program is, of course, src2pkg. It's just a small script-based program which acts as a front-end to the src2pkg functions which are located in separate files. src2pkg also includes the trackinstall program which is a drop-in replacement for the checkinstall program which used to be included with Slackware. trackinstall works much like checkinstall -it's meant to create a package from sources or other content which have already been uncompressed and configured/compiled if necessary. Usage is similar to checkinstall which is already familiar to many users. src2pkg also includes a very simple program called tracklist which only creates a list of files and directories which are created when you run a command.

The usage and options of trackinstall is very similar to src2pkg itself. The main difference is that trackinstall has fewer options since it only does half the work of src2pkg. More details about trackinstall are found elsewhere in this wiki.

Using src2pkg from the command line is very easy. The number of command-line options available is purposely limited so that the user has less to remember and less to be confused by. Using a src2pkg script provides many more options and flexibility, but usage of scripts will be discussed later in this document. We'll also discuss more command-line options and exact syntax later. Here we'll concentrate on the basics needed to get you started. Surprisingly, src2pkg can successfully create a package most of the time without using any advanced options at all.

The simplest way to use src2pkg is to simply type: src2pkg archive-name. Usually when you want to create a package from a source tarball, you should create a new empty directory in which to work. Place the source tarball inside the new directory and then cd into the directory and type src2pkg tarball-name.

When given the name of a compressed source tarball src2pkg performs all the commands necessary to unpack and compile the sources and then install them using the command make install, tracking whatever directories, files or links are created and then making a Slackware-type tgz package from those files, etc.

Giving a valid URL to a source tarball or online *.src2pkg script will automatically download the archive or script for you if you are connected to the internet and then build the package.

src2pkg can usually be used while logged in as a normal user. For some sources which are difficult to package without really installing the software, you must log in as user 'root' or other user with full permissions for writing files and running any commands on the system.

src2pkg was written primarily to create packages from compiled source code which is most commonly available in compressed tar archive format. These are archives which have one of these file extensions: '.tar.gz', '.tgz', '.tar.bz2' or '.tbz'. It can also handle '.rpm' and '.src.rpm' which are RPM archives used by many Linux distributions like Fedora or Mandriva. It also can work with debian source archives using the '.deb' archive suffix.

The above usage is obtained simply by running src2pkg followed by the archive name, like this:

src2pkg archive-name

src2pkg can also serve as a package converter for archives which contain binary or noarch content. Most commonly these are '.rpm' or '.deb' archives, but you can convert nearly any archive that contains content which is already laid-out in a 'skeleton' of the root file system. You can even convert Slackware packages which have been created by other means. One user has reported using src2pkg this way to verify (and correct!) packages which he had created using other build methods.

In this way src2pkg serves as drop-in replacement for the utility called rpm2tgz, at least for the way it is most commonly used -to convert *binary* rpm's to Slackware package format. src2pkg does a better job than rpm2tgz in these cases as it checks and corrects permissions in these 'foreign' archives which may cause problems on your system. It also inserts a description file for the Slackware database which helps to remind you of where it came from and to insure that the package is properly removable with removepkg. However, pointing src2pkg to an .rpm archive which contains *source code* will not simply 'convert' the archive to the '.tgz' format, as rpm2tgz does. Instead, src2pkg will uncompress the archive and attempt to configure and compile the sources. This makes it possible for you to work directly with '.rpm' source archives without having to convert them to another format first.

Usually archives which contain binary programs contain something like 'i486' or other similar notation which indicates the machine architecture which the binaries are built to run on. src2pkg automatically detects name like these for many different architectures and assumes that the archive is a binary package when it finds them. Usage is the same as above for source archives.

src2pkg itself is just a small front-end to the src2pkg functions which are contained in the file /usr/libexec/src2pkg/FUNCTIONS. The functions serve as a sort of packge-building API and contain many options and procedures which can be controlled with more detail by using a *.src2pkg script. src2pkg can create these scripts for you. You can then run them as a separate program or use src2pkg to execute them for you. Once created you can execute them like this:

src2pkg src2pkg-script-name

Or, even easier:

src2pkg -X

Using the -X option causes src2pkg to search for and run the first *.src2pkg or *.src2pkg.auto script that it finds in the current directory. The advantage of running your scripts this way is that you can take advantage of using custom code in your script while still controlling the basic user options from the command line like this: src2pkg -X -VV -C This tells src2pkg to run the src2pkg script, show the full output from all commands and place the final package in the current working directory(CWD).

src2pkg can also work with either archives or src2pkg scripts which are not already on your system in the same way as above, except that you supply src2pkg with a valid URL to the compressed archive or src2pkg script. This makes it really easy to create your own source repository or use those of others. It also makes it possible to 'bootstrap' a system from sources with only a few programs already running on your system. You must be connected to the network or internet for this to work.

Usage is like this:

src2pkg URL-to-archive

Or:

src2pkg URL-to-src2pkg-script-name

Passing extra options to the configure script is the first and most common thing for most users. Many programs will not even compile unless you pass some arguments to the configure script. By default, src2pkg passes only the installation prefix to the configure script. If other options are needed or wanted you can pass them to configure by using the -e= or extra_configs= option to src2pkg. When passing multiple options you should enclose the whole string in single quote marks like this: -e='–disable-tests –enable-static'. If you want to change the –prefix= option you should do that with the -p= option instead of including it with the other configure options. Since src2pkg sets the prefix by default it is done separately.

If the sources contain a .spec file or debian rules file, src2pkg can extract the configure options from these files if used with the -A option. This can often make it easier to get a successful build and will only rarely do the wrong thing. src2pkg will automatically strip out the –prefix option and translate options such as –docdir or –mandir into the proper Slackware options. If src2pkg is run with the -Q option, when it reaches the configuration stage it will run the ./configure –help command in the sources so you can easily see the available options. It will pause and wait for you to input any extra options before proceeding with configuration. For finer control you can always have src2pkg write a src2pkg script for you with the -A or -N option and then edit it and re-run the build to have the changes take effect. src2pkg does not pass any options at all by default, except for the –prefix option. This is because even the most basic and seemingly universal options will cause more failures than they prevent.

The options for src2pkg can be divided into categories several ways, depending on which aspect we are talking about. The syntax used is slightly different from many Linux programs in order to keep it very simple to use. For command-line usage, options are divided into two types – user options and build options.

User options are those which don't directly affect the package content. They are usually given as a single capital letter and do not take any arguments. Examples are the options -A, -N or -W. Three notable exceptions to the single-letter rule above, are the options for choosing the installation method to use. These are -REAL, -JAIL and -DEST (or -DESTDIR) which is the default.

Build options usually have a direct effect on the package content. They are given as small letters and require one or more arguments which is separated from the option name with an '=' sign and usually enclosed with single-quotes. Examples are: -e='–disable-gnome', -d='README AUTHORS'. Most of the build options also have a long version. The above examples could also be written as -extra_configs='–disable-gnome' and -doclist='README AUTHORS'.

src2pkg [User Options] [Build Options] file-name

src2pkg -[ABCDHINOPRSTUV(VV)WX] [-DEST,JAIL,REAL] [abcdefimnpsuv] file-name

The following options take no argument:

• -A Autogenerate a src2pkg script when and if the build succeeds.

• -B Keep backup of any files overwritten by this installation.

• -C Place finished package in Current directory.

• -D Don't apply diff or patch files automatically.

• -H Place finished package in your HOME directory.

• -I Install the created package when finished.

• -N Generate a starting src2pkg script and description file only.

• -O Use an OBJECT directory for building (USE_OBJ_DIR='YES').

• -P Preserve permissions in the source directory. (CORRECT_PERMS='NO')

• -Q Query the user for interactive options during configuration and package creation.

• -R Replay errors in configuration or compilation(useful in QUIET mode).

• -S Use a Shell script for installation(install.sh by default)

• -T Test-build the source code without attempting to make a package.

• -U Update the build script for compatibility if needed.

• -V DEBUG -show detailed prompts for debugging.

• -VV Be verbose. Show all output from the steps (QUIET='NO').

• -W Remove (wipe out) temporary build files (CLEANUP=ALL).

• -X Execute a build script in the current working directory.

• -JAIL Run installation commands in a 'jailed' root directory.

• -REAL Run installation commands in the real root filesystem using backup.

• -DEST Run installation commands using the DESTDIR variable if possible.

The long version is more explanatory but also can make for very long command lines. The long versions of the Build Options match the names of the variables and options as used internally by src2pkg and as used in src2pkg scripts, except that they are all capitals. In other words, if you use the ”-e=” or ”-extra_configs=” option from the command line, src2pkg will translate that to “EXTRA_CONFIGS=” internally. It would also appear this way in a src2pkg script.

The following options require an argument separated by the '=' sign: Use quotes ' ' or ” ” around the arguments if they contain spaces.

• -a Set the architecture of the package [-a=noarch] (ARCH=' ').
• -b Set the build or release number [-b=2] (BUILD=' ').
• -c Set the CONFIG_COMMAND option -usually 'configure'.
• -d Set the list of douments to include [-d='README AUTHORS'] (DOCLIST=' ').
• -e Pass extra arguments to configure [-e='–disable-gnome'] (EXTRA_CONFIGS=' ').
• -f Set the CFLAGS variable [-f='-Wall -O3'] (STD_FLAGS=' ').
• -i Set the install command line [-i='make install'] (INSTALL_LINE).
• -m Set the 'make' command [-m='make dep all'] (MAKE_COMMAND).
• -n Set the package name [-n='newname'] (ALT_NAME=' ').
• -p Set the installation prefix [-p=/usr] (PRE_FIX=' ').
• -s Set the configuration subdir [-s=src] (CONFIG_SUBDIR=' ').
• -u Set the URL location of the source tarball.
• -v Set the version of the package [-v=0.0.0a] (ALT_VERSION=' '). Note: Variables shown above in parenthesis are the src2pkg script equivalents.
• -e Pass extra arguments to configure [-e='–disable-gnome'] (EXTRA_CONFIGS=' ').
• -f Set the CFLAGS variable [-f='-Wall -O3'] (STD_FLAGS=' ').
• -i Set the install command line [-i='make install'] (INSTALL_LINE).
• -m Set the 'make' command [-m='make dep all'] (MAKE_COMMAND).
• -n Set the package name [-n='newname'] (ALT_NAME=' ').
• -p Set the installation prefix [-p=/usr] (PRE_FIX=' ').
• -s Set the configuration subdir [-s=src] (CONFIG_SUBDIR=' ').
• -u Set the URL location of the source tarball.
• -v Set the version of the package [-v=0.0.0a] (ALT_VERSION=' '). Note: Variables shown above in parenthesis are the src2pkg script equivalents.

EXAMPLES:

src2pkg myprogram-0.1.tar.bz2

src2pkg -N myprogram-0.1.tar.bz2

src2pkg -i='make install install-data'-A myprogram-0.1.tar.bz2

src2pkg -e='–disable-nls' -A myprogram-0.1.tar.bz2

Internally, the src2pkg functions use hundreds of variables which allow for lots of flexibility of usage and make it easier to read, understand and extend the capabilities of src2pkg. However, the variables usually have long names to better describe what the variable does, and are written in all capital letters with underlines between the words like this: SOME_VARIABLE This makes the variables 'stand out' in the code but makes them hard to use from the command-line.

src2pkg and trackinstall were written principally to provide a command-line interface to shorten the length of the command line and to provide command-line syntax similar to what is used with most other programs.

Only the most commonly used options are included in the src2pkg and trackinstall programs. Otherwise the help pages would be several screens long and overwhelm the user with the number of options. Command-line options fall into two broad classes which we call 'user options' and 'build options'. Each class of options uses a different type of syntax which makes it easier to remember.

These options are given on the command line with (usually) a single capital letter and do not require or accept any argument to the option, typically like this: src2pkg -T archive-name

This (-T) is a useful example as it shows how to use src2pkg just to see if a source archive will successfully compile on your system. The '-T' option means to just test the build and is written like this: 'TEST_BUILD=1' internally. When given this option, src2pkg only runs through the first part of the build -decompressing, configuring and compiling the sources without trying to install them or create a package. It prints out a prompt to tell you whether the program could be compiled or not.

Another common option of this type is '-N' or '-A'. These are the options used to cause src2pkg to write a src2pkg script for you. The difference is this:

The '-N' option means something like 'NEW' or 'NOBUILD'. If you use this option src2pkg will write a src2pkg build script for the archive-name that you give. It will also create a default package description (slack-desc) file for the package. It does this without trying to locate, uncompress, compile or build the archive-name you give. It will, in fact, write a build script for a tarball which is not on your system, or which you have given the *wrong* name for.

The '-A' options stands for AUTO_SCRIPT. In contrast to the '-N' option, the '-A' causes src2pkg to write the build script for you *after* the build is finished and only if the build succeeds. This means that the archive-name or URL must be valid. The default description file (slack-desc) is created and inserted into the package tree and a *copy* of it is placed in the current directory, unless you have started out by supplying one in the current directory. Note that src2pkg always inserts a slack-desc if none is found -even when no command-line arguments are given.

When src2pkg first creates a build script it adds '.auto' to the name like this:

NAME.src2pkg.auto

This serves 2 purposes: It shows at a glance that the script was generated automatically. If you hand-edit the script or have passed other options (especially build options) to src2pkg when creating the script, you should change the name of the script to simply name.src2pkg. This keeps src2pkg from overwriting the file if you run src2pkg again with the '-N' option.

The same is true for the default slack-desc files created. They are named new.slack-desc to avoid overwriting any existing slack-desc file in the current directory.

Internally src2pkg recognizes and treats both '*.src2pkg' and '*.src2pkg.auto' files the same. However, if you edit the new.slack-desc file you *must* change the name of it to simply: slack-desc for it to be included in the package.

I usually begin the process of building a package by using '-N' option. Then I edit the new.slack-desc file and change the name of it to just 'slack-desc'. Then I begin the build by using 'src2pkg -X' to execute the name.sr2pkg.auto script. I only change the name of the NAME.src2pkg.auto script to just NAME.src2pkg if I have passed build options during script creation, or if I add code to the script. This way I can tell at a glance if the script contains any extra or unusual instructions.

Both the '-N' and '-A' options will write build options that you give on the command-line into the NAME.src2pkg.auto script produced. But since the scripts generated with the '-A' option are written *after* the build, they may contain other options which are used internally when src2pkg discovers something unusual about the sources or configuration method. These are mostly noted for your information. Sometimes they are filled in but then commented out. This is done in order to not break the portability of your script for use by others or on a different OS version or machine architecture.

Another often-used User Option is '-W' which means to WIPEOUT or delete temporary files created during the package build process. this includes the SRC_DIR, PKG_DIR and any logs or build reports which have been created during the build. It does *not* remove src2pkg scripts or slack-desc files.

Using the '-I' option tells src2pkg to install the final package to your system so that it is registered with the system package database. src2pkg uses a miniature internal version of installpkg to do this, so it will work even to compile and upgrade pktools or if no pkgtools are present on the system. Group-builds are made easy this way allowing you to build and install packages as you go which are required by later builds. This is especially useful for building things like GNOME or XORG. Hundreds of packages can be built with a single command by using a small script which loops through a list of sources. some examples are included in the documentation. Of course you test each build and make sure the order is correct.

Most user options are used to control the general behavior of src2pkg and do not have any effect on the content of the package itself.

The build options are used to control and modify the content of the package or the way it is created and they require you to supply an argument to the option. These options use all lowercase letters and require an argument. For most either a short or long syntax is accepted so that, for example, -m='make dep all' could also be written as:–make_comand='make dep all'. If the options contain spaces the whole option line should be quoted. The long forms usually correspond to the way the option is written internally, except the letters are all capitals like this: MAKE_COMMAND. This is the syntax used in a src2pkg script. If you are having src2pkg write a src2pkg script and you pass these options with arguments to src2pkg, they will be written into the script with script-style syntax. The following command: src2pkg -N -m='make progname tests' archive-name would create a src2pkg script that includes this line:

MAKE_COMMAND='make progname tests'

This is the same as running 'make progname' and 'make tests' in the sources

For most users this is the most commonly used option of all. Many sources won't build properly or won't build at all without passing some options to the configure script. src2pkg automatically passes the –prefix='??' option (/usr by default) to configure. But sometimes you need to add something to that, like –enable-shared, –with-included-gettext or –disable-tests. This is done by using the -e='??' or –extra_configs='??' option with src2pkg similar to this: -e='–enable-shared –disable-tests' When you run src2pkg or a src2pkg script like this you'll see the extar options have added after the –prefix='??' configure option.

Using the -d='??' (–doclist='??' DOCLIST) lets you control which documents are included in the final package, if needed. Otherwise src2pkg searches the uncompressed sources for commonly named files which are part of any complete package -usually at least a README, AUTHORS, FAQ and, most importantly, a copy of the license the software is released under.

This is another commonly used option. By default, src2pkg tries to create the contents of the package by executing the command 'make install' and carefully logging what happens. Files, links and directories which are created on your system are then copied into the temporary PKG_DIR used by src2pkg to create the final compressed, installable package.

Packages that don't install with 'make install': Some sources need extra rules passed to install in order to install features or documentation. You can change the command used by src2pkg by passing the command line normally used to install the software, like this: src2pkg -i='make install install_data'

Using 'install.sh', '.bin' or .'run' or interactive installers: You can also use src2pkg or trackinstall to create packages which use binary or script-based installers. Even interactive installations can be tracked this way, though it is worth pointing out that otherwise src2pkg contains no interactive routines at all. src2pkg asks no questions… Example: scr2pkg -i='sh install.sh' This option can be further specified by passing the -S option to src2pkg. This tells it specifically not to try to configure or compile the contents of the source archive and will, by default, substitute the 'make install' command with 'sh install.sh'. It also makes sure that src2pkg runs in verbose mode when the command is run, in case the installer is interactive. If you normally run src2pkg in the default quiet mode, the verbosity is returned to quiet mode after the command finishes.

Note that if you are trying to compile sources which must be *configured* interactively, you must run src2pkg in verbose mode using the -VV option. This happens very rarely, but if you normally run in quiet mode and find that a build is hanging-up or stopping during configuration or installation, try running the build with the verbosity turned up using the -VV option.

trackinstall is an accessory program which is installed as part of the src2pkg package. It is a drop-in replacement for the 'checkinstall' program which used to be inluded with Slackware. trackinstall is used for creating packages from software which has already been configured and compiled. Whereas src2pkg takes care of finding the source archive, creating temporary directories, unpacking the archive, configuring the sources and compiling them, then creating package content usually from the results of the 'make install' command, trackinstall only performs the last of these steps. Both src2pkg and trackinstall perform several steps after the initial package content is created which add to or modify the package content to create a final package which is conformant with the norms followed by official Slackware packages.

Many users prefer to just use trackinstall since they are already familiar with checkinstall. And trackinstall is sometimes easier to use when creating packages from certain kinds of content. Still, I recommend that you use the full src2pkg program when possible as it allows you to easily control and repeat all the steps for making a package and also allows you to keep a script which you can use later for duplicating the process. This is especially useful if the software requires special handling or commands during configuration and compiling. Having a script keeps you from forgetting the exact steps or configuration options needed.

The options and syntax usage for trackinstall are mostly the same as for src2pkg, except that the options for the steps for the early processes such as unpacking the sources and configuration are not included.

tracklist is a simple program which is included in the src2pkg package. It simply creates a log of all files and directories created by a command, without doing any modifications of the files or creating a package. It is completely non-intrusive and creates a file called FILELIST in your home directory which shows the files and directories created. Usually you'd use it like this: 'tracklist make install' or perhaps like: 'tracklist sh install.sh' It will track most any command with arguments.