Breaking long dependency chains

[Freek Dijkstra]

Hi Ryan at al.,

First of all, let me thank you for your effort in making MacPorts.
I hope that this discussion may give one or two improvements to increase
its popularity.

I'm well aware that whatever I propose will not be easy, and that always
blindly depending on Apple-provided tools is not the answer (if I
thought it was, I would have switched to a different package manager.
The fact that I have not tells enough).


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

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

I question this policy.

I fully agree that MacPorts should provide a full-featured software for
'requested' ports (perhaps even "the most full-featured"), but MacPorts
should only provide a minimal featured software set for 'leaves' ports.

Again, this is my argument that if X depends on Y, and Y depends on Z,
that does not mean that X depends on Z: X may only use those features of
Y that do not depend on Z.

A prime example is if X is a small tool like rubber, which uses the
command-line features of Y (Y being a script language or document
parser, for example pdflatex), where Y also provides some GUI or other
feature that causes it to depend on a whole slew of dependencies (like
X11) which is not required by X.

Now I must admit that I don't have a quick solution here, but it seems
to me that the above is the cause of the long dependency chains.

A possible solution is perhaps to split packages like Y -- which provide
both a GUI and a command line (think texlive) into two packages: the
command-line core, and the GUI tools. A prime example of sheer
awesomeness in this case are the recent splits of Python into a core
python package (with few dependencies) and separate py27-tkinter and
py27-gdbm packages.

Debian provides the ability to use a single source package (port) with
multiple installed packages. I know texlive does some neat trickery in
this respect, but I can't find info about this in the Portfile
documentation. Is that supported, and should it?

Is the above suggestion to split packages into a smaller parts a good
solution? Or would you prefer to use multiple variants?



>> * 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:
> 
* [change of Apple provide X11 from XFree86 to Xorg]
* [removal of autoconf and automake in XCode 4.3]

Thanks for these examples.

I previously distinguished between library, build and fetch
dependencies., and argued that MacPorts should rely on its own
dependencies for library dependencies, but that it is not required for
build and fetch dependencies.

I must admit that your examples show that depending on Apple provided
tools, even for fetch dependencies, is a risk.

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

Remember that a new Mac OS release would require a full recompile of all
ports anyway, and I'm not recommending this for library dependencies.

Do you think this additional effort (and additional uncertainty about
future Apple releases) would be worth it?


Concluding -- I think there are ways to improve the current situation,
and if I find some examples, I'm happy to file a bugreport or provide a
patch. It is just that the FAQ is disparaging the issue (it talks about
"minimal" effect and wasting a few megabyte and little time due to fast
CPU -- in my experience, /opt/local is a few Gigabyte, and compiling
takes hours, not minutes). Also, it seems to miss the point that not all
dependencies are strictly required.

Regards,
Freek