Index: en_US.ISO8859-1/books/porters-handbook/special/chapter.xml =================================================================== --- en_US.ISO8859-1/books/porters-handbook/special/chapter.xml +++ en_US.ISO8859-1/books/porters-handbook/special/chapter.xml @@ -91,6 +91,117 @@ /boot/modules. + + Bundled Libraries + + This section explains why bundled dependencies are + considered bad form and what to do about them. + + + Why Bundled Libraries Are Bad + + Some software requires you to look for third-party + libraries yourself and adding the required dependencies to + your port, while other software bundles all those libraries + in their distribution. While the latter seems easier at first + sight, there are some serious drawbacks: + + The following list is loosely based on the Fedora + and Gentoo + wikis, both licensed under the CC-BY-SA + 3.0 license. + + + + Security If vulnerabilities are + found in the upstream library and fixed there, they might + not be fixed in the library bundled with your port. One + reason could be that the author is not aware of the + problem. This means that you have to fix them yourself or + upgrade to a non-vulnerable version, and send a patch to + the author. This all takes time, which results in + software being vulnerable longer than necessary. This in + turn makes it harder to coordinate a fix without + unnecessarily leaking information about the + vulnerability. + + + + Bugs This problem is similar to + the problem with security in the last paragraph, but + generally less severe. + + + + Forking It is easier for the + author to fork the upstream library once it is bundled. + While convenient on first sight, it means that the code + diverges from upstream making it harder to address + security or other problems with the software. One reason + for this is that patching becomes harder. + + Another problem of forking is that because code + diverges from upstream, bugs get solved over and over + again instead of just once at a central location. This + defeats the idea of open source software in the first + place. + + + + Symbol collisions When a library + is installed on the system, it might collide with the + bundled version. This can cause immediate errors at + compile or link time. It can also cause errors when + running the program which might be harder to track down. + The latter problem could be caused because the versions of + the two libraries are incompatible. + + + + Licensing When bundling projects + from different sources, license issues can arise more + easily, especially when licenses are incompatible. + + + + Waste of resources Bundled + libraries waste resources on several levels. It takes + longer to build the actual application, especially if + these libraries are already present on the system. At + run-time, they can take up unnecessary memory when the + system-wide library is already loaded by one program and + the bundled library gets loaded by another program. + + + + Waste of effort When a library + needs patches for &os;, these patches have to be + duplicated again in the bundled library. This wastes + developer time because the patches might not apply + cleanly. It can also be hard to notice that these patches + are required in the first place. + + + + + + What to do About Bundled Libraries + + Whenever possible, use the unbundled version of the + library by adding a LIB_DEPENDS to your + port. If such a port does not exist yet, consider creating + it. + + Bundled libraries should only be used if upstream has a + good track record on security and using unbundled versions + leads to overly complex patches. + + + + Shared Libraries