Breaking long dependency chains

[Ryan Schmidt]

On Mar 18, 2012, at 13:00, Freek Dijkstra wrote:

> Of course, they is NOT required. Many of dependencies are completely
> unnecessary.

Obviously, if any dependencies are completely unnecessary, they should not be there. However, usually we know what we're doing, and don't add unnecessary dependencies. If you find a case where we have indeed added an unnecessary dependency, by all means file a bug report.


> Some suggestions:
> * Reduce the number of dependencies. A good example is Python, which no
> longer depends on GTK (it is no longer required to specify the
> no_tkinter variant)
> * Pick the least inclusive variant by default. In particular, do not
> include gtk or x11 dependencies if not required.

MacPorts policy is to provide the most full-featured software by default, not the least.


> Let me think out-of-the box here.
> * Keep track of manually installed and automatically installed packages.
> This ensures that it easier to start over, and that no
> no-longer-required dependencies remain installed

MacPorts already does so. See the "requested" and "leaves" pseudoports.


> * provide binary packages for a few packages that are installed
> all-the-time. This includes perl, python, xorg.

MacPorts already does so, for Snow Leopard x86_64, for those ports where the licenses of their dependencies allow us to do so, for default variants. We attempt to improve this all the time and offer binaries for more ports, and Mac OS Forge admins are working to give us a Lion buildbot soon.


> * do depend on Mac-based tools for fetch dependencies and (in some
> cases) build dependencies. While I do think that MacPort should build
> its own library (e.g. openssl, perl version, etc.), I do not think that
> it should build its own tools.

MacPorts policy has been to depend on MacPorts ports for dependencies, and not use system programs. Historically, there have been some exceptions, many of which have proven to be bad ideas and which have been or are being rescinded. For example:

* MacPorts used to depend on system X11. This caused a lot of headaches especially when system X11 switched from XFree86 to Xorg between Tiger and Leopard. Things are much happier now that we have ports in MacPorts for Xorg X11 and always use it. Word is Mountain Lion will remove system X11 completely which makes us even happier about our decision.
* Xcode always used to provide autoconf and automake, which some ports need, but guess what? Apple removed autoconf and automake from Xcode in 4.3. We've already been preferring for a long time that ports should use MacPorts autoconf and automake, and this decision by Apple reinforces that preference as well.

Some of these exceptions are unlikely to change. For example, we're probably always going to require Xcode, for its compilers; we're unlikely to start using MacPorts compilers to compile everything, since it would be a chicken-and-egg problem to get that MacPorts compiler compiled in the first place (unless we chose to bundle a pre-compiled version with the MacPorts installer). Similarly, we're likely to continue using Apple's Tcl, since MacPorts itself is written in Tcl and requires Tcl to run, so unless we decide to included a copy of Tcl with the MacPorts installer, we'll use Apple's. But as much as possible we want to insulate MacPorts from incompatible changes that Apple continues to be prone to make in OS X.