Make yap build packages using OCI containers under the hood

[Polpetta]

Currently Yap builds inside a container. This is somewhat cumbersome, because every time you need to build something you need to spin up the right "version" of yap with the target distro you want to build a package for.

I propose instead to reverse this: we make yap capable of manage OCI images (either with podman or docker) and once the related distro is launched, perform the package build inside the container, and then copy the artifact back to the host. This way from a user point of view you have only one yap installed in /usr/bin and from there you're able to build for every distro you want, since docker/podman will be used under the hood to build for different distros.

Benefits:

• No more necessity to launch the right container for building for a desired target, yap will manage itself
• Only one binary installed in the host machine, so KISS 💯
• You can build in parallel packages for different distros, since you can spin up different containers at the same time and save up time instead of sequentially build them. This is great not only for "personal usage", but also to CI/CD systems that usually have many cores. This way we can leverage the full power of the server 😏

Thell me what you think 😁

[apontini]

How are you going to get every image though? It would be expensive to install them all and it, the solution might be to host them and download them on the docker hub.
+1 for the "copying the artifact back to the host" though because right now generated artifacts are owned by root only

[Polpetta]

Yes, we could prepare some "default images" with a set of dev tools already installed, to speed up the container build. Maybe we should give the possibility to customize this to the end user in multi-build project setup, via yap.json file.

Note that there are two possibilities here: either use docker build to get the artifact (this would even using layer cache and will save time on multiple run) or run a container and from the inside of it perform the build. In the first case buildah could be another possible tool to be compatible with (they all have the same command line syntax, so it is easy to build one generic controller for all of the platforms mentioned before)