Create a package (tarball) for distribution

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search

This article assumes you want to download and build some software from the software's source code. It further assumes the source code is available as some tar file (a tar ball). In the first section it is assumed that the software source follows a common structure and comes with a common mechanism (GNU build system) to build it. In the section chapter a workaround is described for getting along with other cases.

Since there are many, many different software packages out there, there is no guarantee that the particular package can be build exactly as described here. There is no guarantee that it is packed as a tar file, and there is no guarantee that you have everything to build it. That's why many packages come with documentation! It might sound shocking, but it is a clever idea to read that one first. Often the documentation also explains what additional tools and libraries are needed to build the software, and how to fine-tune the build.

The remainder of this article further assumes you have all the common development tools installed.

Building GNU build system based Software

Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the GNU build system. The most apparent hint, but not an absolute proof, is the existence of an onfigure script which is supposed to be run to configure the build system for the current platform.

For a GNU build system the configure script usually has been created with

  • GNU autoconf and using
  • GNU automake and
  • GNU libtool.

Further the source code author should have used autoconf, automake correctly and in compliance with the GNU coding standards by keeping directory output variables in the Makefiles unexpanded. This allows to use make install and overriding install locations. This is a feature which is used later in this description in order to prepare for packaging. In case the author did not confine to these rules you may try to fix this by using pack_sync script as described below.

1) Download the source to a preferred place:

#I suggest to create a folder on /dev/hda3.../mnt/ on ppc-LS, /mnt/hda/ on the LS2
mkdir -p <compiling-folder> 
cd <compiling-folder>    
wget http://<download-location>/<app-source>

2) Untar the package - use xzvf if it has a tar.gz-extension (=.tgz) and xjvf if it has tar.bz2

tar xzvf <app-source>.tar.gz

3) change into the new directory

cd <app-source>

4) check which options are available for ./configure by executing

./configure --help

5) configure the application with the right prefix for the final destination (e.g. /usr/local), instead of your local temporary installation directory PACKAGE/usr/local. If you cross-compile you also need to point to the cross compiler, linker, assembler.

./configure --prefix=/usr/local CC=... ...

Further options to be considered may be --sysconfdir, --infodir, and --mandir 6) Compile, but don't install the application


7) Become root


8) Clean and prepare the temporary installation directory structure to which the package will be temporarily installed. This cleanup ensures that no left-overs from previous build attempts or accidentally moved files will be packaged, too. Warning: If you do this on the wrong directory, you might accidentally delete your whole Linux system ...

rm -rf PACKAGE # DANGER Don't do this with the the wrong directory!
# Create temporary version of the prefix directory
mkdir -p PACKAGE/usr/local

9) Install the compiled application into your temporary packaging directory. For that you need to temporarily overriding the prefix setting. This installation must not trigger a recompilation, and it won't if the software author has created the configure system correctly. The installation should keep path information already compiled into the application and related files. That is, the application should contain the final destination pathes, as set with --prefix=... when configure was run.

make install prefix=PACKAGE/usr/local

Further options to be specified may be infodir and mandir.

Building Non-GNU build system Software

In case the software author didn't create the configuring system as properly as assumed by the previous step you may fix this by pack_sync tool. This requires that you have installed the software to your running system in advance.

1) up to 4) Just same as above.

5) Configure

# Create temporary version of the prefix directory
mkdir -p PACKAGE/usr/local
# configure the application with the same paths as for the provious 'real' installation,
# prefixed by '$PWD/PACKAGE':
./configure --prefix=$PWD/PACKAGE/usr/local --sysconfdir=$PWD/PACKAGE/etc ...
Again, --infodir, and --mandir may have to be used.

6) and 7) Same as above.

8) Same as above, except that mkdir -p PACKAGE/usr/local has already been done.

9) Install the compiled application then to your temporary packaging directory:

make install 

Since you have pointed the --prefix to some local path you probably have a package which can't be installed anywhere else than on <some strange path>/PACKAGE/usr/local while you really want it to be working in /usr/local. This is because the package may contain files with hard-coded paths. In order to fix this problem these files must be replaced by the corresponding files of your previous real installation. pack_sync tool may be used for this purpose:

./pack_sync PACKAGE

If you are really using 'PACKAGE' you may omitt this (default parameter). The script takes a walk thru the directory tree starting with PACKAGE by calling itself recursively. It compares all files with those of the living system (same directory path but w/o prefix $PWD/PACKAGE). If there are differences you are prompted to confirm a replacement. Note: <br\>- You may deny replacement, get informed about the differences and rerun pack_sync later. <br\>- pack_sync doesn't provide an undo of it's replacements.

10) Continue with the next chapter

Please find a discussion about sense or non-sense of pack_sync tool in the discussion area.

Package the built Software


After the software has finally been build (see the previous chapters), one can now wrap the stuff up in a package for distribution. A simple package would be a tar file, a more convenient package would be an ipkg package. The following sections describe both alternatives.

Scripting the build as described above, and the packaging might make sense, instead of typing the same commands again and again.

Package as a tar File

tar is the traditional Unix archiving program, which is still popular in the Unix and also Linux world. It was originally intended for tape archives, but for ages it is used for file archives. These days a tar file is often compressed in addition, to reduce its size.

For packing the built software perform the following steps:

p1) Become (or stay) root. p2) Pack and compress the data in one go

tar cvzf <appname>_<architecture>.tar.gz -C PACKAGE .

where architecture should be ppc for LS1/HG/HS, mips for the LS2 and arm9 for the LS Pro.

That's it.

Package as an ipkg

ipkg is the package management tool chosen for OpenLink. Building ipkg packages is much simpler than it might appear at first sight. This wiki contains rater extensive ipkg documentation, particular Construct ipkg packages (for developers).

The following is just a quick rundown of what to do, so one doesn't get distracted by the multiple ways of creating an ipkg package. The details can be found in the referenced documentation.

  1. Decide if additional install and remove scripts are needed. E.g. to automate otherwise tricky setup steps, to display a license during install, to ask the user for some configuration parameters, to merge existing configuration, etc.
  2. Write the script(s), if any.
    See Construct ipkg packages (for developers)#Scripts for details.
  3. Create a package description (control) file. This is mandatory.
    See Construct ipkg packages (for developers)#CONTROL/control file (mandatory) and Construct ipkg packages (for developers)#Sample CONTROL/control files for details.
  4. Become (or stay) root.
  5. Create a directory called CONTROL in your PACKAGE directory:
  6. Store the scripts (if any), and the control file in the PACKAGE/CONTROL directory and give them proper file access rights:
    cp <scripts ...> control PACKAGE/CONTROL; chmod a+rx PACKAGE/CONTROL/<scripts ...>; chmod a+r PACKAGE/CONTROL/control
  7. Run ipkg-build:
    ipkg-build -c PACKAGE
    See Construct ipkg packages (for developers)#Using ipkg-build from ipkg-utils for details, but ignore the statements about tedious setup. That "tedious" setup was already performed by building the software in the PACKAGE directory as described in one of the above chapters.

That's it.