Upstream Bundles
Many projects borrow source files from each other, sometimes modify them in their own repositories and slipstream them into their products. This practice is considered harmful for several reasons:
- When dependencies get updated, project developers have to rebundle them. Most of the time they just ignore updates. Security implications are bad.
- Compatibility is gradually obliterated. Software can no longer use new versions of its dependencies.
- Shared source does not get back the improvements projects introduce. While this sounds pro-GPL, it isn't really about licensing.
- Disk/memory resources are wasted. This is clear in case of shared binary libraries, this might more or less apply in other cases.
Some projects try to install bundled dependencies in the same locations as they are installed separately. This results in conflicts.
With all that in mind, we should understand that bundles are the only way vendors can distribute software on some platforms without highly developed package management. You can't ask windows users to download php classes before they can run some web application. In fact, only a fraction of M$ users will get through Apache and MySQL configuration. Same goes for the bulk of Linux distros, each with different combination of major shlib versions. The net result is everything from free and open source Firefox to free and closed-source Oracle and most non-free solutions come bundled with precompiled dependencies.
Upak pursues multiple targets here:
- Attempt to automate identification and identify upstream bundles
- Understand what prevents bundled dependencies from inclusion into major package collections
- Enumerate the difficulties products may have when switching from bundled versions to separate ones
- Attempt to find a streamlined way for such a switch