#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:

and change into T2 source directory. All T2 commands are run from inside the source-tree, that you should also update from time, to time:

Using the T2 source based build system you can simply install package using the top-level "t2" script (previously "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:

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

Rebuilding vital packages w/ known cross compile issues

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

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:

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

As some packages, including the system compiler and C library are considere vital, they are not upgraded by default and the educated user can choose for themselves whether and when they want to upgrade them.

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:

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 and map those to packages 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 dependency resolution. Due to that there are can be overly complex dependency chainsm, e.g. often with modern KDE and GNOME pkgs, that will cause build errors and require manually adding this secondary dependencies in case of build errors. For such exceptions, for now a little common sense has to be applied to derive potentially missing pkg from build errors:

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:

As a professional power user, you might realize you do not need some or none of the optional dependencies, cancel the build, and disable dependency resolution to specify only the ones you like to install:

For future releases we not only plan to work on improving the automatically cached dependencies, we also plan to annotate at least the most important optional dependencies, so future updates will more often ask whether to install optional dependencies, too.

Rebuild binutils for accurate build time estimates

T2 is caching package build times using the Binutils package as reference time. If you want the T2 build system to estimate the time needed to build a package more cosistently, simple once force the re-build of binutils to store it's reference time:

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.