Skip to content
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 policy on static libraries #15870

Merged
merged 4 commits into from
Aug 15, 2023
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 6 additions & 0 deletions docs/Acceptable-Formulae.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,12 @@ Clang is the default C/C++ compiler on macOS (and has been for a long time). Sof

We're a package manager so we want to do things like resolve dependencies and set up applications for our users. If things require too much manual intervention then they aren't useful in a package manager.

### Static libraries

In general, packages should not ship static libraries since these cannot be updated without a rebuild of the dependant software.
If a package gets a lot of requests to provide static libraries, they may be provided by the package.
SMillerDev marked this conversation as resolved.
Show resolved Hide resolved
Applications in homebrew/core linking against libraries should link against shared libraries not static versions.

### Stuff that requires vendored versions of Homebrew formulae

Homebrew formulae should avoid having multiple, separate, upstream projects bundled together in a single package to avoid shipping outdated/insecure versions of software that is already a formula. Veracode's [State of Software Security report](https://www.veracode.com/blog/research/announcing-state-software-security-v11-open-source-edition) concludes:
Expand Down