I would just chime in to suggest a slight variation on the “Docker running on a CI/CD” solution talked above.
Background: I have experience in building packages - old school RPMs (barebone
rpmbuild, in chroot containers
mock), older RPM buildsystems (
koji), more modern buildsystems (to me OBS is what Koji should have been, but I never managed to get my then employer to shift), and end-user packaging systems (such as conda: I am mostly contributing to bioconda nowadays at work).
Conda has an interesting approach that works in channels:
semi-centralized repository of multiple recipes.
That would be a way to solve the complains of @nekron:
In the end it comes to the situation that community will have a fragmented build and repository space for non-harbour compliant applications.
Instead we could imagine that some communities, e.g.: openrepos, handle giant collection of SPEC recipes, and the CI/CD scripts of that repository handle the recursive compilation of all recipes (or at least all the new ones in a commit/pull-request, etc.) when a project necessitates multiple package, they will be just seen as multiple SPECs in the same channel.
Another interesting effect, is that most package will have their recipe to build from source centralized in a few places. So if Jolla decides to introduce AArch64, it will be seen as just yet another target for which to build the recipes in a channel.
- It’s not unlike AArch64 showing up as another possible target build arch in OBS.
- It’s much better than the current “hunt every developper on openrepos, hope that they still pay attention to requests/messages, and pester them until they do yet another build on they local SDK/Docker and manually upload it” into which we are heading with the disappearance of OBS.
(I know that F-Droid is also having such a concept of “the repo is in charge with building the software, not each individual developper” but I don’t have any dev experience there).