Hi arch team, after receiving your email on repod, here is an idea. What I have been asking myself since the python db scripts arrived at the arch gitlab instance. "Why doesn't arch consider writing yaml files with makepkg instead of the various formats in pkg.tar, db.tar, files.tar and links.tar?" For the sake of argument of the idea, I assume yaml to be the file format, but it could be json too. So here is the idea, that would certainly not materialize over night if it was implemented. Maybe for pacman 7+ ? It is not be about implementation details atm, just about a general idea to cure some shortcomings in the build process. What if: 1. PKGBUILD was in yaml 2. makepkg/pacman handled, read/write yaml files, ie standardize the file formats to yaml * pkg.tar: PKGINFO yaml(would contain the MTREE as a node), BUILDINFO yaml, maybe refactor these if there is redundant data * it might even be possible to use parts of the PKGBUILD yaml in code for the above, once read, it can be queried and/or reused * db.tar: a unified db consisting of one yaml for each package 3. *repod directly handled* these yaml files and tar'ed them in a new db instead of writing the json from the various formats and files as it is the case currently * there is a lot of redundancy in the current build process up to some repo operation in terms of writing, reading files in different formats The idea would be to *base everything on yaml*, which eventually raises the question on the viability of makepkg/repo-add in bash. Maybe python? However, yaml writing could even be done in bash, replacing the current formats. Afaik, arch plans have been to have one git repo per package and these connected to a CI? It is much more easy to feed some structured data format to a CI in my view, so that's the main thought behind the idea. We have been having a CI/CD running for some years now, and the shortcomings are, that its not easy to hook into makepkg process to have say a dedicated CI test stage, the check() function in PKGBUILD. A yaml based PKGBUILD would allow to have these makepkg stages easily accessible by the CI and run them each in their own stage with proper makepkg flags. To have a little glimpse what a PKGBUILD in yaml might look like, here it is: $ pkg2yaml artixlinux/main/udev/trunk --- pkgbase: name: udev pkgver: 251.2 pkgrel: 2 url: https://www.github.com/systemd/systemd arch: - x86_64 license: - GPL2 - LGPL2.1 makedepends: - acl - libacl.so - kmod - libkmod.so - util-linux - libblkid.so - hwdata - libcap - libcap.so - kbd - gperf - intltool - git - meson - docbook-xsl - rsync - python-jinja packages: - pkgname: udev depends: - acl - libacl.so - kmod - libkmod.so - util-linux - libblkid.so - libudev - hwdata - kbd provides: - udev=251.2 - pkgname: libudev depends: - gcc-libs provides: - libudev.so - pkgname: esysusers groups: - base-devel depends: - gcc-libs - libxcrypt - pkgname: etmpfiles groups: - base-devel depends: - acl - libacl.so - libcap - libcap.so version: 251.2-2 files: - udev-251.2-2-x86_64.pkg.tar.zst - libudev-251.2-2-x86_64.pkg.tar.zst - esysusers-251.2-2-x86_64.pkg.tar.zst - etmpfiles-251.2-2-x86_64.pkg.tar.zst debug: ``` The yaml representation doesn't contain any functions so far, and thus there is no separate makepkg implementation, but I have been considering it for our CI for quite a while. Our CI gets all necessary information from the yaml. In theory, build jobs could use PKGBUILD dependencies and do queue checks for example before building a given package. This is the PKGBUILD side of things, thus better implemented upstream pacman. In my humble opinion, addressing the repod first is the wrong end to start, if you want a CI based build system. If everything was in yaml, repod could simply directly handle these yaml files and tar them as db, very streamlined approach. In its current state, repod would only be of limited use for us, since we don't add packages asynchronously to the repo. They are added on build success by our CI via a repo-add/links-add wrapper called in a stage. I hope it doesn't sound all too crazy, its a pretty radical and work intensive idea, but that would be my vision for a complete set of build and repo management tools easy to connect to some CI. An async repo management tool could be built on top of such a structure. Kind regards Artoo