Breaking long dependency chains

[Ryan Schmidt]

On Mar 19, 2012, at 05:49, Freek Dijkstra wrote:

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

Regardless whether this would be useful, the MacPorts dependency engine that doesn't work that way.

A MacPorts port can declare a dependency on another MacPorts port, but it cannot declare a dependency on a specific variant of that port. This is one of our oldest tickets (#126), yet it's one I'm not convinced should ever be fixed. What if you install port A which depends on port X with variant +foo, and then you install port B which depends on port X with variant +bar? Does MacPorts install X +bar thus breaking A which required X +foo? Or does MacPorts install X +bar+foo? What if the two variants conflict with one another?

We used to recommend that ports enable as many commonly-used features as practical. Uncommon features could be added as variants ("+foo"), and common features that took a long time to build and/or had lots of dependencies could be turned off with negative variants ("+no_bar"). As of MacPorts 2, which can remember which variants you've turned off, we've deprecated negative variants and instead recommend regular variants that are turned on by default.

MacPorts does not have the capability at present to decide what variants to install a port with based on whether the port was requested or not. I don't think this would be a good thing to add either, because MacPorts does not have the capability at present to rebuild a dependency with a different set of variants either.

Basically our goal should continue to be to reduce or eliminate variants, not increase their proliferation.


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

Yes, MacPorts recently gained this feature; we call it "subports". The unified python, perl5 and php portgroups use subports, as do individual ports like pianobar, pure, VillainousStyle, and php54 (in my users directory). Since the feature is a recent addition, many ports that really should be split into subports have not yet been split.


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

Subports are good; variants are bad. We should definitely split ports into subports where appropriate.


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

As Lawrence pointed out, our existing "file" dependency types are sufficient for this, and we should employ them where appropriate.