Source repos, binary repos ========================== Topics: - Derive target binary repository from source repository - Target service (e.g. https://archlinux.org) - Target repository (e.g. `[core]`) - Support for split-package to multi-target binary repository - Creation of new source repository - Move of package source between repositories and repository targets - What goes into V1 and V2? - v1 would be ssh based like dbscripts(?) - v2 might be API based ## Source repositories 1. ACLs on package sources correlate with ACLs for binary repository location (e.g. `uri:///pkgs/<acl_group>/<package>`) 2. Package location in binary repository can be set or overridden by descriptor file, per package in a pkgbase (e.g. `.DBINFO` file defines location for `package_a` and `package_b` for pkgbase `package`) 3. Build/package tooling takes into consideration the ACLs of the source repositories and incorporates overrides ### .DBINFO v1: <pre> lib32-glibc multilib glibc core </pre> v2: <pre> - pkgname: lib32-glibc repo: multilib tests: | gcc -o main.c file /usr/bin/ld - pkgname: glibc repo: core </pre> ## Binary repositories 1. A repository by default defines its debug, staging, testing and stable location (i.e. `name`, `debug`, `staging`, `testing`) 2. An uplink to the source repository of each binary package is added as separate metadata to the management repository 3. ## Scenarios ### Flat source directory structure - Packages are located in a flat structure (e.g. `url://pkgs/<package>/`) ### Hierarchical directory structure - Packages are located in a hierarchical structure (e.g. `url://pkgs/<repo>/<package>/`) ### Group maintenace - We might want to have group based package maintainership in the future - pkgs/go-tean/<package>