A Plea to Reduce Dependences (e.g., for swig)

[Ryan Schmidt]

On Aug 16, 2011, at 17:08, M.E. O'Neill wrote:

> I summarized my feelings about swig's dependencies with this diagram:
> 
> 	http://i.imgur.com/S6vyf.png

FYI, in case you made that diagram by hand, we also have the port-depgraph script to generate things:

https://trac.macports.org/browser/contrib/port-depgraph

And also the depTree.py script which works similarly:

https://trac.macports.org/browser/users/eborisch/macports_utils


> I'm not necessarily saying that it's bad to link to MacPorts-specific libraries, but it strikes me as highly questionable that someone wanting to use swig to make interfaces for Java programs needs to install an X server and a full install of python and perl and a variety of other software that is has no connection whatsoever to this task.  

Note that this won't actually happen. swig-java depends on kaffe, but if you look into the swig portgroup you'll see this is declared as "bin:java:kaffe". The reasoning is that swig-java requires Java, but the version of Java provided with Mac OS X is fine, so we use that if available (which on Mac OS X it always is). The kaffe dependency is only there for non-Mac OS X systems that might not already have a Java implementation. Which means the dependencies installed by swig-java are in fact much more reasonable, as diagrammed here:

http://ryandesign.com/tmp/swig-java.pdf


> Similarly, some ports pull in things that really really make no sense.  At all.  My favorite is GHC, which includes a dependency on perl5.8. Yes, 5.8. Why?  Because GHC uses perl in its build system.  The system perl works fine, but hey, MacPorts will install an ancient perl just 'cos.

According to the comment in the ghc portfile, only Perl 5.8 is usable. I don't understand the details of why.

The ghc port is rather out of date. Unfortunately our ghc maintainer has not been very active in recent years. If somebody else is interested in taking over ghc, perhaps that would help.

There is an open request to update it to a later version:

http://trac.macports.org/ticket/25558


> And yes, I think the FAQ is far too dismissive of how much of an issue it is to pull in a hundreds of megabytes of other libraries. If MacPorts didn't have a propensity to compile everything from source, it might be one thing to make people install vast libraries of software they have no actual need of.  But compilation does take time.

MacPorts 2.0.0 introduced our buildbot and installing from binaries. We (primarily Joshua!) are still sorting through the ports that the builtbot is failing to build, and fixing them, so over time, more and more ports should be available as quick binary installs.


> There is a huge difference in usability between "I need swig [...five minutes pass...] I have swig, yay!" and "I need swig [...hours pass...] I guess it's installing libxml now, I wonder when it'll be done...?"  Plus, ports break, and so you run the risk of "I can't install swig because freetype won't build today. Argh!".
> 
> Likewise, while diskspace is often cheap, the equation isn't so simple as you may think.  If you have a MacBook Air with a 64 GB SSD, you may be watching you disk space usage carefully.  Similarly, megabytes do matter when some people need to pay for bandwidth (e.g., over a 3G connection).


Yes, the rise in popularity of SSDs does set us back somewhat on our mantra of disk space being cheap. But I do believe that the quality of MacPorts would drop and ports would break if we follow the strategy you suggest. (Maybe not on Lion today, but on Lion in three years, and on Leopard and Tiger today.) Our policy of including nearly every feature a software provides means there aren't surprises when users (or the ports they've requested) request optional features that aren't available.