-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the reasons for using Mock / key features #1481
Comments
Notes for later:
|
There probably should be a mention that mock goes out of its way to have a shared cache of downloaded RPMs, which is significant when you build a lot of packages. It (and abovementioned things) kinda sorta can be implemented with lots of bash and docker/podman, but then you essentially end up reimplementing mock badly, and mock is already using containers when it can. I've been thinking of forgoing mock because of some warts it has that make my workflow inconvenient sometimes, thinking I would just implement a subset of what mock does, but in the end I've ended up discovering lots of edge cases mock already handles capably. |
We frequently explain why plain "rpmbuild call in podman/buildah" isn't a replacement for Mock. It would be nice to have documentation documenting the key benefits of Mock from this perspective (with some technical details).
/note for myself: ADR
The text was updated successfully, but these errors were encountered: