Unverified Commit cdb482b3 authored by David Runge's avatar David Runge
Browse files

README.rst: Adding examples for per-package plaintext files based tracking of...

README.rst: Adding examples for per-package plaintext files based tracking of versions and per-repo plaintext files based tracking of package versions (both don't hold any further packge information but name and version).
parent f11b98b0
......@@ -22,7 +22,7 @@ managed by their maintainers::
Following is an attempt to draw out a couple of potential designs for how to
keep track of which version of which package is currently in which (binary
package) repository.
They all share a common design: Keep track of all available `PKGBUILD`_ files
Some share a common design: Keep track of all available `PKGBUILD`_ files
of all packages in a single (`architecture`_ specific, e.g. *x86_64*)
repository (grouped by repository)::
......@@ -47,6 +47,54 @@ repository (grouped by repository)::
multilib-staging
multilib-testing
Others follow a more minimalistic approach, in which tracking of the package
repositories is only done indirectly. In these scenarios, *a)* per repository
plaintext files keep track of the packages and their respective current
versions, or *b)* per package plaintext files in repository directories keep
track of their respective versions.
a)::
x86_64
core.txt
core-debug.txt
extra.txt
extra-debug.txt
staging.txt
testing.txt
community.txt
community-debug.txt
community-staging.txt
community-testing.txt
gnome-unstable.txt
kde-unstable.txt
multilib.txt
multilib-debug.txt
multilib-staging.txt
multilib-testing.txt
b)::
x86_64
core
package_a.txt
core-debug
extra
package_b.txt
extra-debug
staging
testing
community
community-debug
community-staging
community-testing
gnome-unstable
kde-unstable
multilib
multilib-debug
multilib-staging
multilib-testing
Per-architecture monorepo using subtree
=======================================
......@@ -100,6 +148,49 @@ The different packages are tracked using `git-submodule`_.
- `git-log`_ only reflects to which commit a submodule was updated
- needs ``submodule init --update --recursive`` to be fully functional
Per-architecture repo with per-repo plaintext file
==================================================
The package names and versions are tracked in per-repository plaintext files
(e.g. `x86_64/core.txt`)::
package_a 0.0.1
package_b 0.2.1
**Pros**:
- very simple
- very fast
- only few files
- no additional git plumbing required
- package moving (between repositories) requires operations on two files
**Cons**:
- intransparent (package details can not be retrieved in one place)
- per package build scripts are held separately
Per-architecture repo with per-package plaintext file in repo directories
=========================================================================
The package versions are tracked in per-package plaintext files in repository
directory structures (e.g. `x86_64/core/package_a.txt`)::
0.0.1
**Pros**:
- very simple
- very fast
- as many plaintext files as there are packages
- no additional git plumbing required
- package moving (between repositories) requires one file move operation
**Cons**:
- intransparent (package details can not be retrieved in one place)
- per package build scripts are held separately
Binary repository layout
________________________
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment