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.

Sign up for GitHub

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

Expanding on 'no vendored dependencies' #433

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Expanding on 'no vendored dependencies' #433

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions vcpkg/contributing/maintainer-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -266,6 +266,21 @@ message(STATUS "See the overlay ports documentation at https://github.com/micros
Do not use embedded copies of libraries.
All dependencies should be split out and packaged separately so they can be updated and maintained.

Vendored dependencies introduce several challenges that conflict with vcpkg’s goals of providing a reliable, consistent, and maintainable package management system:

Difficulty in Updates: Embedded copies of libraries make it harder to track and apply updates, including security patches, from the upstream projects. This leads to potential security risks and outdated dependencies in the ecosystem.

Symbol Conflicts: Vendored dependencies can cause symbol conflicts when multiple packages include different versions of the same library.

For example:
If Package A vendors Library X (version 1) and Package B vendors Library X (version 2), an application linking both packages may experience runtime errors or undefined behavior due to conflicting symbols.

By packaging dependencies separately, vcpkg ensures a single version of a library is used across all packages, eliminating such conflicts.

Licensing Compliance: Vendored dependencies can obscure the licensing of the embedded libraries, potentially violating their terms or creating compatibility issues.

Increased Maintenance Burden: Keeping vendored dependencies in sync with their upstream versions requires significant manual effort and often leads to duplicated work across packages.

### Prefer using CMake

When multiple buildsystems are available, prefer using CMake.
Expand Down