Infrastructure

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]