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

[Anders F Björklund]

M.E. O'Neill wrote:

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

If you are lucky...

There is no one perl or one python, so you could end up with 4 or so ?
(perl5.8 perl5.10 perl5.12 perl5.14  python24 python25 python26 python27)

The user is free to point "perl" and "python" to any of those versions.

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

The previous +system_x11 variant did this, it would use $x11prefix
(/usr/X11R6 or /usr/X11 depending on your system version) rather
than install new ports in $prefix (for xorg). It's now deprecated,
in favor of installing a MacPorts version of X11 from www.X.org...


It's perfectly possible to have MacPorts live with the system versions,
as you have done in your own variants. There's "bin:" and "lib:" schemes
to allow any program or any library (including system) to fill in deps.
But the policy for quite some time has been to disallow it, for "port:"

Of course, this doesn't apply to everything. It will still default to
using system GCC and system Make, even if there are ports for those ?
Looking at the system from the "outside", it's sometimes very hard to
tell why some things must use prefix and some things must use system. :-P


It seems unlikely that the policy will be reversed very soon, though.

--anders