Breaking long dependency chains

[Lawrence Velázquez]

On Mar 19, 2012, at 6:49 a.m., Freek Dijkstra wrote:

> A suggestion -- would it be possible to provide virtual packages for
> Apple-provided tools, like apple-perl, apple-python2, apple-subversion?
> This sure may be a cause of problems, but perhaps its limited when these
> dependencies would only be used for fetch and/or build dependencies? I'm
> not suggestion to blindly accept all Apple packages. For example, a
> package which says "just give me any Python version" or "any gcc-like
> compiler is fine" is likely to run in problems soon. However, I do not
> see a problem with a package that specifically asks "please provide
> Python2.7" or "please provide gcc4.4 or llvm 3.0".

MacPorts currently has file dependencies[1], which allow ports to depend on the existence of a certain file rather than the presence of a MacPorts package. For example, as Ryan showed earlier, netpbm has a file dependency on the system Subversion if it's new enough:

    % port -v deps netpbm
    Full Name: netpbm @10.47.31_0
    Fetch Dependencies:   bin:svn:subversion
    Build Dependencies:   path:bin/perl:perl5
    Library Dependencies: port:zlib, port:jpeg, port:tiff, port:libpng, port:jasper,
                          port:jbigkit, port:libxml2

This means that MacPorts will look for a binary called "svn" in the usual places before falling back to installing the subversion package.

[1] http://guide.macports.org/#reference.dependencies.types

vq