#9 Creating a new T2 package tutorial

This is a short introduction how T2 packagess are created. We try to give a initial overview and focus on examples. For detailed and complete information please read the corresponding sections in the handbook.

All examples are extracted from real T2 packages and linked to the corresponding files in our T2 SVN trunk. However, since T2 development is steadily going on, it code sniplets will differ from the linked content. We try to keep this tutorial up to date, though you may even encounter some dead links in case a package has been (re)moved.

Introduction

T2 is using low-code package metadata descriptions, specifing the source download URLs, human readable text or cpu architecture masks. Usually no code needs to be written, as the t2 package manager will automatically build most standard build system types. Only if packages require non-standard guidance (hacks) to compile or complex boostrap, shell scripting code can be added to hook into the t2 build in a fine grained modular way. Even .patch files are applied automatically, optionally selected by cpu architecture or libc mask extensions, like .powerpc, .musl.

This does not only save time while creating a package, it also simplifies updating packages as not much code has to be reviewed or adapted during each update. Additionally it also allows T2 targets the flexibility to build packages differently, with other options, patches or only install a sub-set of the files the packages installs by default.

The packages are located in the package/ directory, grouped into several repository such as base/, xorg/ and so on.

A T2 package consists of at least a .desc file - containing the package's metadata, an optional .conf file - with script code (if any), and a .cache file - containing the detected dependencies, buildtime and size. The .cache file is automatically generated by the T2 build system and only needs to be copied by the initial package creator after a successful test from /var/adm/cache/. As the .cache file also holds the dependencies, the build system will fill the dependencies as detected by the used .h, .a, .so and simillar files during the build in the T2 sandbox.

A simple package example

Let's take a look into a package's .desc, for example: package/develop/libsigc++/libsigc++.desc

The metadata consists of key-value pairs, that look like array assignments: [A], [D], [V], ... The keys used are abbreviations for Author, Download, Version. A comprehensive descriptions is available in the handbook.

Most of the tags are informal, for either the developers or the end-user installer. The most important tags for the build system are the Download tag [D], as well as the Priority tag [P] or Flags [F].

The easiest way to create a new package is to just copy a simillar existing package and modifythe tags.

Testing the new package

After the package's .desc was created, the package can be tested using the normal T2 way to build a single package:

Which, depending on the type and nature of the package most often alread succeeds at the first try due T2's automatic build system!

Fixing a package to build

As noted earlier the automatic build system of T2 recognizes quite some different build systems of packages, including but not limitted to classic Makefiles, GNU/Autoconf, Perl and Python modules and uses sane defaults (depending on the actual build configuration) to build the package. Only if the package is not modelled after a recognized build styles, or does not build with the latest compiler or alternative libc used in T2, further code is required.

To patch the upstream pkg sources, it is enough to simply drop the diff modification with the extension .patch into the package directory.

Other packages might require special arguments for the configure script, make, or make install which can be added to the .conf file in the following way:

Sometimes more intrusive guirance might be necessary, for example if a package has no install target, the make install step can be disabled and the files manually installed like:

For further documentation about the sheer endless possibilities in .conf files, the the handbook or contact the core developers.

Adding the cache file

Once the package built and was verified to work, the generated cache file can be copied into the package directory:

so that the dependencies are also available to other people building the package.

Sending in the new package

To share your work with all the other T2 developers and users it's best to send the newly created files to the t2 project.

The Author

René Rebe studied computer science and digital media science at the University of Applied Sciences of Berlin, Germany. He is the founder of the T2 Linux SDE, ExactImage, and contributer to various projects in the open source ecosystem for more than 20 years, now. He also founded the Berlin-based software company ExactCODE GmbH. A company dedicated to reliable software solutions that just work, every day.