Hey HN!
The problem: adding one RPM to an S3-hosted repo meant downloading the entire metadata, regenerating everything locally, and uploading back. For large repos this takes minutes per package and causes race conditions with parallel builds.
rpmrepo-update solves this with incremental updates:
- Only touches the metadata entries for the package being added/removed
- Uses S3 ETag for optimistic locking (no race conditions)
- Adding a package is O(1) instead of O(repo size)
Typical use case: CI pipeline builds an RPM and publishes to S3 repo in seconds, not minutes.
Written in Go, single binary, works with AWS S3 and MinIO. MIT licensed.
Would love feedback, especially from anyone managing large RPM repositories or running into similar CI bottlenecks.
Hey HN! The problem: adding one RPM to an S3-hosted repo meant downloading the entire metadata, regenerating everything locally, and uploading back. For large repos this takes minutes per package and causes race conditions with parallel builds.
rpmrepo-update solves this with incremental updates: - Only touches the metadata entries for the package being added/removed - Uses S3 ETag for optimistic locking (no race conditions) - Adding a package is O(1) instead of O(repo size)
Typical use case: CI pipeline builds an RPM and publishes to S3 repo in seconds, not minutes.
Written in Go, single binary, works with AWS S3 and MinIO. MIT licensed.
Would love feedback, especially from anyone managing large RPM repositories or running into similar CI bottlenecks.