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

[M.E. O'Neill]

Ryan wrote:
> 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 did write a quick script to do it.  It was just a few minutes of recreational coding.  I'm not surprised others have done the same, and no doubt more polished.  FWIW, this was mine:

	http://pastebin.com/KGbeTSbz

> [using kaffe] 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".  Which means the dependencies installed by swig-java are in fact much more reasonable

Well, that's good, but that still leaves swig-perl installing a custom perl and swig-python installing a custom python.  It still seems unreasonable to me that because I want to use something that *generates* perl code, I should have MacPorts perl installed.  In fact in general, for development tools, it seems like a strange assumption that those tools should be *targeting* the MacPorts environment just because they were installed via MacPorts.

>> 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

The GHC folks have an installer package and many people use that.   The out-of-date-ness of the MacPorts port is arguably a positive in that regard, encouraging people to use a better-supported and less baggage-laden version.

> 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.

One of the strengths of MacPorts is its variants system.  It doesn't seem unreasonable to me to have a +systemlibs variant that as much as possible tries to use the system libraries, at least for things that directly or indirectly pull in a lot of baggage.

In this envisioned scheme, at the point where a +systemlibs variant of a package becomes untenable, it goes away.

Essentially this is what I already do myself.  I regularly hack Portfiles to remove dependencies that the software doesn't actually need.  It's usually trivial, as it was in swig; here's all I did to render it "sane" from my perspective:

	http://pastebin.com/dVGJuxrp

If I were good, I'd have done it as a variant myself, but I'm a bad bad person.

    M.E.O.