Source code Theca

Private package repository

• About
• Installation
• Infrastructure
• Traho
• Index

About

Theca is a custom eopkg repository. eopkg is the packaging format conceived and adopted by Solus Project, a Linux desktop distribution built from scratch.

This private repository was born by the need of having a place where to put custom packages which were not included by default on official repository (such as the Pantheon Desktop stack, left out from Solus-Project repository due to legitimate reasons).

Installation

The enablement is done using the eopkg toolset:

eopkg add-repo Theca https://solus.davidepucci.it/eopkg-index.xml.xz

Use unstable version

eopkg add-repo Unstable https://unstable.solus.davidepucci.it/eopkg-index.xml.xz

Install Desktops components

As switching between different Desktop Environments very easily leads to lot of log-on and graphical issues, often permanent, here is a quick instructions set to have a functional clean Solus installation along with a custom DE:

• Follow the standard procedure to install a fresh Budgie-based Solus installation.
• Reboot and enter the terminal, adding the Theca repository as suggested above.
• Update repositories indexes:

eopkg ur

• Install the desired DE (e.g., Pantheon Desktop):

eopkg it -y -c desktop.pantheon

• Purge the systems from Budgie related packages:

eopkg rm -y baobab budgie-desktop-branding eog \
    gnome-calculator gnome-calendar gnome-disk-utility \
    gnome-doc-utils gnome-mpv gnome-photos gnome-screenshot \
    gnome-system-monitor gnome-terminal gnome-themes-extra \
    gnome-user-docs nautilus nautilus-extension \
    nautilus-python rhythmbox rhythmbox-alternative-toolbar

• Reboot and log-on choosing Pantheon Desktop from the DE menu.
• Enter the terminal and only then remove final Budgie leftovers:

eopkg rm -y budgie-desktop

Infrastructure

Source code

The source code repository is including two kind of entities:

1. packages templates: these ones represent the instructions needed to the eopkg build tool to generate the corresponding installable package;
2. build automation scripts: these are basically a collection of Bash/Python based snippets used to do concurrent and incremental build of packages as well to wrap them up to make them fit into a legal eopkg repository.

On the other hand, what is being generated by the combination of the ones above, the effective eopkg files are released relying on GitHub Releases functionality, in a perfectly eopkg compliant structure.

Building

The repository offers a Makefile configuration, used to batch do things, such as running a common repository full build or a check for packages pending updates.

The build order is dictated by the src/series file: this is needed as several packages have build dependencies inside the repository itself. Hence, the series file splits all the packages in several subsequent iteration groups, which assure that a specific package-x gets built and indexed on the local (in-build) repository before the depending package-y package.

Also, in order to make the whole process work, solbuild (the tool used to build the package starting from a package.yml template) needs to be configured to treat the local build directory as a local repository. This can be done by creating the /etc/solbuild/theca-x86_64.profile settings and adding the following lines:

image = "main-x86_64"

add_repos = ["Theca-Local", "Theca-Upstream", "Solus"]

[repo.Theca-Local]
uri = "/path/to/theca/build"
local = true
autoindex = true

[repo.Theca-Upstream]
uri = "https://unstable.solus.davidepucci.it/eopkg-index.xml.xz"

[repo.Solus]
uri = "https://mirrors.rit.edu/solus/packages/shannon/eopkg-index.xml.xz"

Hosting

The whole repository is hosted on GitHub: the packages templates and build instructions in the Git repository itself, while the built eopkg files and the indexes are kept in dedicated repository releases.

Furtermore, iin order to deal with the growth of the packages supported by the repository and be able to test them in a simpler and more flawless way, an unstable variant of the repository has been introduced.

From the hosting point of view, nothing really changes: instead of a single release, the projects relies on two different ones, each for a different variant of the repository.

To proxy requests from davidepucci.it subdomain to the corresponding GitHub release, the following PHP engine is used:

<?php

if (strlen($_SERVER['REQUEST_URI']) == 0
        || strcmp($_SERVER['REQUEST_URI'], '/') == 0) {
    header("location: https://davidepucci.it/doc/theca");
} elseif (substr($_SERVER['SERVER_NAME'], 0, 8) === "unstable") {
    header("location: https://github.com/streambinder/theca/releases/download/unstable".$_SERVER['REQUEST_URI']);
} else {
    header("location: https://github.com/streambinder/theca/releases/download/stable".$_SERVER['REQUEST_URI']);
}

This way, the solus.davidepucci.it host behaves as a poor and rough proxy, redirecting dynamically the requests without taking charge of the traffic generated by repository indexes and packages downloads.

Also, this .htaccess is used to forward all the files GET requests to the PHP snippet above:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [L,QSA]

Traho

Traho (originally Solbump) is a tool to automatically upgrade eopkg YAML-formatted source files to latest releases.

Based on the amount of defined (and pluggable) providers, it tries to recognize the format of the tarballs or archives defined as source files from the YAML file and find a matching provider. Then it's able to query for a more updated release and, if so, it fetches the asset, calculates the hashsum and update the original package.yml coherently.

Usage

Before starting using the tool, further actions need to be taken, in order to access all its capabilities. In fact, few providers could be in the need of API tokens or specific configurations. So create the configuration file at ~/.config/traho and, depending on your needs, fill it with data you own:

# To obtain the token, go to:
# https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line#creating-a-token
# Traho does not require any scope to be enabled.
github:
    api: habmfnlzrwmxuopmjganlqfpmccouxieijlouxcl

# To obtain the token, go to:
# https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
# Traho requires only the API access scope enablement.
gitlab:
    api: hmlhnbzndrogcifs-akb
    domains:
        - name: gitlab.xfce.org
          api: zzDkdnNCq9JaX5UfZJZC

Using the tool is pretty straightforward:

traho package1.yml package2/package.yml

Installation

Package manager

Installation from repositories is only available for Solus Project users which have enabled Theca repository:

eopkg it -y traho

GO toolset

go get github.com/streambinder/traho

Index