#8 Getting started w/ a fresh T2 install

So you installed T2 on a new system and want to install additional, latest and greatest open source software or update the already pre-installed packages. In this article we compiled a summary of the most important steps to get you started:

As T2 is a source based, rolling release Linux distribution, you first need the latest T2 sources including it's meta-data of package build recipes. Since August 2023 this sources come pre-installed in /usr/src/t2-src, for older or more minimal installation sets, you can simply check them out via Subversion (SVN, just like Git ;-) with:

svn co https://svn.exactcode.de/t2/trunk /usr/src/t2-src

and change into T2 source directory. All T2 commands are run from inside the source-tree:

cd /usr/src/t2-src

Using the T2 source based build system you can simply install package using "scripts/Emerge-Pkg". The scripts determine dependencies, and on the first invocation also copy the installed system configuration from /etc/SDE-CONFIG to the source tree's config/default. For example to install the Lua scripting language, you can simply run:

scripts/Emerge-Pkg lua

Usually that would already be all you need to know to install new software packages and it's dependencies. However, there are some complications we like to point out:

Rebuilding vital packages w/ known cross compile issues

As T2 dev team intentionally cross compiles all ISOs —so all architecture builds are created equal— no matter the build host. ARM or RISCV. To have identical configuration and uncover build issues for all builds quickly. However, some packages must be re-build to be fully functional. Perl and Python are currently the main offenders. To build some, more complex source packages (such as KDE, GNOME, but also Wine or Qemu), first rebuild those:

scripts/Emerge-Pkg -deps=none -f perl perl-xml-parser \
python pip setuptools meson ninja libtool libxml

Keeping your whole system up-to-date

To keep up-to-date with latest bug and security fixes, released daily by all the individual Open Source projects, it is recommended to run Emerge-Pkg as often as necessariy for your level of expected system security for the packages already installed in the system:

scripts/Emerge-Pkg -system

Which will result in a set of package updates to be build similar to:

> gcc ... New version (13.1.0 -> 13.1.1). Vital, skipped by default.
> openssl ... New version (1.1.1t -> 1.1.1u). Added.

As some packages, including the system compiler and C library are considere vital, they are not build by default and the educated user can choose for themselves if the want to manually schedule them for update.

Gobject-Introspection

If you plan to install Gtk-based components of the GNOME desktop environment, you most likely also need to rebuild some of it's base packages. This is because at the time of writing, gobject-introspection does not support cross-compilation as it requires to run native helper binaries to process the annoated source code for introspection. While we plan to tackle this issue in the future, for now you need rebuild those packages in order to have the .gir gobject introspection data generated for other packages:

scripts/Emerge-Pkg -f gobject-introspection gdk-pixbuf pango \
harfbuzz at-spi2-core graphene gtk

Broken, stray dependencies

As we believe in automation, T2 does not use human curated dependency information, and instead relies on our build sandbox to cache all accessed file information to map those to package for dependencies. While this usually works quite well, modern complex sources often unintentionally pull in various random false positives, e.g thru Python and other such meta data registries and build artefacts. While we work on ironing and filtering out the last remaining random fake depencies, our scripts/Emerge does currently only perfom one-level, direct depenency resolution. Due to that there are can be overly complex compendency chains (e.g. often with modern KDE and GNOME pkgs) that will cause build errors and require manually adding this secondary depencneis in case of build errors. For such exceptions, for now a little common sense has to be used to derive potentially missing pkg from build errors:

t.b.d. example build error missing X

In this case X is missing and has to be added together with the original pkg you want to install to the Emerge arguments.

Too many dependencies

As T2's sandbox currently tries to cache the maximally required dependencies, Emerge might at times want to build more than you would like to install. For example:

scripts/Emerge-Pkg php
> php ... Not installed. Added.
php> brotli ... Not installed. Added.
php> cyrus-sasl2 ... Not installed. Added.
php> openldap ... Not installed. Added.
4 packages scheduled to build: brotli cyrus-sasl2 openldap php

As a professional power user, you might realize you don't need some or none of the optional depenencies, and thus cancel the build, and disable dependency resolution and specify only the ones you like to install:

scripts/Emerge-Pkg -deps=none brotli php

For future releases we not only plan to work in improving the automatically cached dependencies, we also plan to annotate (at least the most important) optoinal dependencies, so future updates of Emerge-Pkg will provide feedback and ask whether to install optional dependencies, too.

Rebuild binutils for build time estimates

T2 is caching package build times using the Binutils package as time reference. If you want the T2 build scripts estimate the time neded to build a package you need to once force re-build binutils to have it's reference time available:

scripts/Emerge-Pkg -deps=none -f binutils

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.