General goals #193

New Issue

Jef Roosens · 2022-05-23T17:36:06+02:00

Jef Roosens commented

2022-05-23 17:36:06 +02:00

I have a few broad goals in mind that I want to accomplish before releasing version 1.0.0.

Dependency resolving

I have no intention of adding support for AUR dependencies specifically. However, a user could add the AUR dependencies for their package to their Vieter system as well. For this approach to work, Vieter would have to resolve a dependency graph to make sure the dependencies are built before their dependent packages. Besides this, builds should be able to use packages from Vieter repositories. Perhaps these repositories could be added automatically, if Vieter detects it's needed.

Reduce pressure on (official) repositories

Different builds often use a few of the same dependencies. That combined with the regular rebuilding of base images does cause the build host to download a lot of packages from the repositories. By sending each request to a repository through a caching server, this could drastically reduce the amount of downloads actually processed by the repositories. Pacolo could be added to the build containers' network for this purpose.

Reduce compile times

Rust or C++ packages often require a long time & a lot of computing power to compile. If the package in question is a development package as well, this could result in a lot of compilation being done on the server very reqularly.

These compile times can be greatly reduced using ccache, or in this case, sccache. Using only environment variables, both the cmake & cargo build systems can be configured to use sccache for caching. A Minio S3 server could be set up inside the build containers' network for very fast network speeds. Alternatively, an external S3 server could be used, either a self-hosted one or a paid service.

Full build system configuration using API

Any configuration of the build system should be possible using the server's web API & its respective CLI commands. Only thing the cron instance should need to know is the server's address & API key.

Granular configuration

It should be possible to configure any setting as granually or broadly as needed. For example, the global cron schedule should be able to be configured globally for ease, or per repo, or per arch-repo. Same idea goes for the mirrorlist, extra packages to install, or any other settings that might be added later on.

I have a few broad goals in mind that I want to accomplish before releasing version 1.0.0. ### Dependency resolving I have no intention of adding support for AUR dependencies specifically. However, a user could add the AUR dependencies for their package to their Vieter system as well. For this approach to work, Vieter would have to resolve a dependency graph to make sure the dependencies are built before their dependent packages. Besides this, builds should be able to use packages from Vieter repositories. Perhaps these repositories could be added automatically, if Vieter detects it's needed. ### Reduce pressure on (official) repositories Different builds often use a few of the same dependencies. That combined with the regular rebuilding of base images does cause the build host to download a lot of packages from the repositories. By sending each request to a repository through a caching server, this could drastically reduce the amount of downloads actually processed by the repositories. [Pacolo](https://github.com/anatol/pacoloco) could be added to the build containers' network for this purpose. ### Reduce compile times Rust or C++ packages often require a long time & a lot of computing power to compile. If the package in question is a development package as well, this could result in a lot of compilation being done on the server very reqularly. These compile times can be greatly reduced using ccache, or in this case, sccache. Using only environment variables, both the cmake & cargo build systems can be configured to use sccache for caching. A Minio S3 server could be set up inside the build containers' network for very fast network speeds. Alternatively, an external S3 server could be used, either a self-hosted one or a paid service. ### Full build system configuration using API Any configuration of the build system should be possible using the server's web API & its respective CLI commands. Only thing the cron instance should need to know is the server's address & API key. ### Granular configuration It should be possible to configure any setting as granually or broadly as needed. For example, the global cron schedule should be able to be configured globally for ease, or per repo, or per arch-repo. Same idea goes for the mirrorlist, extra packages to install, or any other settings that might be added later on.

Jef Roosens added the

Roadmap

label 2022-05-23 17:36:06 +02:00

Sign in to join this conversation.