Problem
I appreciate the effort @slp has put into creating homebrew taps for krunkit. Unfortunately, the slp/krun tap is 429MB on disk after cloning. This is because pre-built bottle tarballs are committed directly into a bottles/ directory in the git tree.
The standard Homebrew convention is to host bottles as GitHub Release assets, keeping the tap repo lightweight. Committing them to git means:
- Every
brew tap slp/krun clones ~429MB
- The size grows with each new version
- Old bottles remain in git history indefinitely
Suggestion
It would be great if the bottles could be moved to GitHub Release assets under the https://github.com/containers/ organisation. The existing tap's git history could be rewritten to remove the blobs (brew update uses git reset, so existing users would be unaffected), or a new tap could be created under the containers org (or alternatively upstreamed to homebrew-core).
Hosting the tap and binaries under containers would also be beneficial from a supply chain perspective. As consumers of these packages, having the tap in the same org and trust boundary as containers/krunkit simplifies downstream security controls and supply chain reviews.
Problem
I appreciate the effort @slp has put into creating homebrew taps for krunkit. Unfortunately, the
slp/kruntap is 429MB on disk after cloning. This is because pre-built bottle tarballs are committed directly into abottles/directory in the git tree.The standard Homebrew convention is to host bottles as GitHub Release assets, keeping the tap repo lightweight. Committing them to git means:
brew tap slp/krunclones ~429MBSuggestion
It would be great if the bottles could be moved to GitHub Release assets under the
https://github.com/containers/organisation. The existing tap's git history could be rewritten to remove the blobs (brew updateusesgit reset, so existing users would be unaffected), or a new tap could be created under thecontainersorg (or alternatively upstreamed tohomebrew-core).Hosting the tap and binaries under
containerswould also be beneficial from a supply chain perspective. As consumers of these packages, having the tap in the same org and trust boundary as containers/krunkit simplifies downstream security controls and supply chain reviews.