Why not bundle dependencies

The intend of this article is to collection information on dependency bundling to make a complete and well-explained page that we can refer upstreams to instead of explaining the same thing over and over again. You are welcome to contribute to this page.

= What is a bundled dependency = Say you develop and distribute a piece of software P: a game, a library, anything. Now a bundled dependency is some other software (or software library) that
 * 1) is shipped with the source code of P and
 * 2) is compiled and used when compiling P

= Temptations = There are reasons why bundling dependencies happens again and again: there are certain benefits to it! So why is it tempting to bundle dependencies?

Comforting non-Linux users
Especially in Windows, shipping dependencies can be a favor to your users to save them manually wiring things together. Without a package manager there is no real-solution to that on Windows anyway. So the temptation is: if you use bundled code on Windows, using it on GNU/Linux too feels consistent and is easy on your mind.

Easing up adoption despite odd dependencies
If your software P has some dependency D that is not yet packaged for major distributions, D makes it harder for P to get in as packaging P forces the new maintainer to package D him/herself or to wait for someone else to package it for him/her. Bundling D hides the dependency on D in a way: if the packager is not paying close attention P may even get in despite and with the bundled dependency. (It's only a matter of time until someone noticed the bundling, though)

= Problems = So why is bundling dependencies bad after all?

Security implications
Most software has security issues, often many of them. When a patch for a security issue becomes available, every installation of that package needs updating. If that package is installed once for the whole system, one package is updated and the system is safe from that very issue. Not so If the dependency has been bundled somewhere. All bundles need to be found an updated. It may included different versions of the same affected code which may need different patches. A huge mess and waste of time.

= Downstream consequences =

Patching
= What to do upstream =
 * (A) Remove bundled dependency
 * At best, remove the bundle dependency and allow compilation against dependency D
 * from either a system-wide installation of it or a local one at any user-defined location.
 * That gives flexibility to users on systems without D packaged and makes it
 * easy to compile against the system copy downstream: cool!


 * (B) Keep bundled dependency, make usage completely optional
 * With a build time option to disable use of the bundled dependency
 * it is possible to bypass it downstream without patching: nice!
 * When keeping dependency D bundled make sure to follow the upstream
 * of D closely and update your copy to a recent version of D on
 * every minor (and major) release to at least reduce the damage done
 * to people using your bundled version a little.

= See also =
 * Gentoo bugs on bundled dependencies