| 187 | | There are several reasons to do so. First, it makes ports more compatible across different versions of Darwin/OS X. If we can rely on e. g. openssl 0.9.8 from MacPorts, we don't have to test every port that needs ssl for every available openssl installation. Apple's software tends to break from time to time (e. g. openssl refuses to build with an old zlib, but Apple shipped the old headers of the vulnerable zlib version). Third reason is up-to-dateness: Apple only features e. g. Python 2.3, not 2.4, with which some software does not work. The drawbacks on this behaviour also are minimal: Wasting 10MB for a Python installation is next to nothing if you have a GB-harddisk and gain consistency all the way in return. |
| | 187 | There are several reasons why MacPorts uses its own libraries. It makes ports more consistent across different versions of Mac OS X. If we can rely on e.g. openssl 0.9.8 from MacPorts, we don't have to test every port that needs ssl for every available openssl installation. Apple's software tends to break from time to time (e.g. openssl refuses to build with an old zlib, but for awhile Apple shipped the old headers of the vulnerable zlib version). Even if Apple's versions aren't broken, they're rarely up-to-date. Apple has a habit of not updating the libraries in Mac OS X until absolutely necessitated by a security vulnerability. |
| | 188 | |
| | 189 | The drawbacks of this policy are minimal: Wasting a few megabytes for e.g. a Python installation is next to nothing if you have a multi-gigabyte hard disk, and the time required to build the additional ports decreases as computers get faster. |
