Product SiteDocumentation Site

Chapter 3. Packaging

3.1. Building Listaller Packages
3.1.1. Prepare your application
3.1.2. Set up the packaging info dir
3.1.3. Create DOAP data
3.1.4. Create file listings
3.1.5. Some finetuning
3.1.6. Build the package
3.1.7. Distribute the package
3.2. Appcompile
3.2.1. What is Appcompile?
3.2.2. How to use Appcompile?
3.3. Depscan - Scan for software dependencies
3.3.1. What is Depscan?
3.3.2. How to use Depscan?
Creating Listaller packages and cross-distro applications is easy. Just follow the instructions below and read the documents.

3.1. Building Listaller Packages

The following instructions will help you creating cross-distro IPK packages for your own application. Please note that Listaller is designed to install applications, so IPK packages will only install applications. Packaging shared libraries using IPK packages is a very bad idea, and although it might be possible, we don't want shared libs packaged in IPK packages. If you have a shared library, you can create a native distribution package and distribute it as DEB/RPM.

3.1.1. Prepare your application

Your application needs to meet some special requirements to be installed on a wide variety of different Linux distributions. (E.g. it must be relocatable) You can read the application development documents for more information on this step (see Chapter 2, Developing Listaller-ready applications).

3.1.2. Set up the packaging info dir

To create a Listaller IPK package, you first need to create a directory containing information about your application and how to build it. The directory should be at toplevel of your source tree (but it does not have to be there) and it should be named ipkinstall. The directory has to contain a pkoptions file, which defines some options for the package build, e.g. if Listaller should try to find dependencies automatically. A minimalistic pkoptions-file might look like this one:
Version: 1.1

AutoFindDeps: true
The Version field should reflect the IPK standard version this package will be build for and NOT the version of your application.
Other files in the IPK source directory are DOAP data for your application (appname.doap), a list of files which should be installed (files-current.list), a Makefile containing rules how to build your app from source (build.rules) and a file describing the dependencies of your application (dependencies.list). All files except for the Makefile and the dependency list are required and have to be present. In the following sections we will show you the basic stuff you can do with these files and how you create them.

3.1.3. Create DOAP data

Listaller uses DOAP to fetch information about your project. You should already have a DOAP description of your project. (it is required e.g. for all GNOME projects and many other projects use it already)
If you don't have DOAP data already, you can generate it, e.g. using DOAP-A-Matic or another tool. For more information about DOAP, you can read this document.
After you generated the data, save it as *appname*.doap in your IPK source dir, where *appname* should be replaced with the name of your application in lowercase. Other options are linking the DOAP file to your IPK source-dir or writing a script which auto-generates the sourcedir when you want to build the IPK package. (if you don't want to store the DOAP data in the IPK-src dir)

3.1.4. Create file listings

Now you need to write a list of the files your application wants to install, so Listaller can add them to the package and copy them to the right locations, when the setup is executed. IPK packages support multiarch setups, so you can define files which have to be installed by architecture, using files-*arch*.list file-lists, where *arch* is the architecture these files belong to. (e.g. ix86, amd64, …) If *arch* is all, files in this file-list will get installed on all architectures.
You can also make Listaller pick the current system architecture and create a package for it. This is usefull if you don't package binary data which is already there, but instead build an IPK package from source. In this case, the file-list needs to be named files-current.list. Files mentioned in this listing will get installed on the current architecture. This is the most common case when building an IPK package.
An IPK file-list can look like this:
# IPK file list for FooBar

:: %APP%
:: %INST%
:: %INST%/data
:: %ICON-16%
icons/16x16.png foobar.png
:: %ICON-32%
icons/32x32.png foobar.png
:: %ICON-64%
icons/64x64.png foobar.png
:: %ICON-128%
icons/128x128.png foobar.png
Lines starting with a :: define the destination directory on the target machine. You should always use a Listaller directory variable there. Absolute paths are possible, but will lower the trust level for your package and will make private package installations impossible. You should in general not use absolute paths. After defining the target directory, you can add a list files which should be installed there, relatively to your source directory. Wildcards are allowed in filenames.


By default, Listaller uss the directory below ipkinstall as source-directory, but you can change this setting by using the FilesRoot field in pkoptions

3.1.5. Some finetuning

Do some manual tweaks if needed.


The documentation is not yet complete. You may want to help extending it.

3.1.6. Build the package

You are now ready to build your IPK package! Just make sure Listaller's command-line tools are installed, then change to the directory below the ipkinstall dir and execute:
			[earth@sun/foobar] lipkgen -b
The build tool should now create an IPK package in the directory below your current dir, which contains all things needed to run your application.
We strongly encourage you to sign your package with your public GPG key. If you don't sign it, Listaller will consider the package as dangerous and GUIs might show a warning message when users want to install the package. To sign the package, just append –sign to the build options:
			[earth@sun/foobar] lipkgen -b --sign
There are also some other flags you can apply to modify the behaviour of lipkgen. If you are interested, you can read the manpage. Usually the extra options should not be needed.

3.1.7. Distribute the package

You can now publish your (signed) package anywhere on the web and have users install it using Listaller. Later, you might want to set-up and update-source for your software, so all users stay up-to-date.