Multi Repository management
I'm a heavy user of Arch Linux and repoctl, and I'm currently setting up a CI/CD pipeline for a few projects on our local network. repoctl is fantastic for managing our package builds, but I've identified a key feature that would dramatically improve our ability to ensure reproducible deployments and simplify rollbacks: repository version control.
I'm eager to help develop and test this feature if you think it aligns with the project's direction!
The Problem: Lack of Package Baseline Snapshots
In a CI/CD environment, we need to know that the exact set of packages that passed testing in "staging" is what hits "production." Currently, managing this baseline and performing reliable rollbacks is challenging.
Requested Commands:
I propose adding two commands to treat the state of the repository as a versionable entity:
-
repoctl commit -m "Commit message"
Function: Saves a lightweight, auditable record (like a package manifest file) containing the exact list of all packages and their versions currently registered in the repository database. This "commit" would serve as a reproducible, deployable baseline snapshot.
Mechanism Suggestion: The saved record could be a simple file containing a list of package-name=version-release entries (e.g., mypkg=1.0.0-1).
-
repoctl checkout <commit_hash | tag>
Function: Restores the physical repository directory and the database to the state defined in the specified commit. This would involve removing or updating package files in the directory to precisely match the commit's manifest, followed by regenerating the repository database.
Key Enhancement for Rollback (ALA Integration):
To make the checkout command truly reliable for historical states, we need a way to fetch old files that may have been aged out of the local cache.
Suggestion: If a required older official package version is missing from local storage during a checkout, repoctl could be configured to attempt to download the specific .pkg.tar.zst file from the Arch Linux Archive (ALA). This ensures that any historical, committed state remains fully reproducible.
This feature would give repoctl a powerful edge in guaranteeing package consistency and simplifying disaster recovery/rollback procedures.
Let me know your thoughts on this proposal! I'm happy to discuss the implementation details or contribute code.
Thanks for maintaining such a great tool! Sorry LLM Generation 😅
Hi @vaytea glad to hear that repoctl provides value to you! I don't see myself personally using the features you suggest but I do also think it aligns with the general goals of repoctl.
The implementation also seems like it would be pretty straightforward. If you want to make a PR, I'd be glad to review.