Dependency Problem of Upgrading Gnuplot: A Possible Bug

[Xin Liu]

> exactly ... that's why the use is discouraged ... it only causes
> problems.

To me it's not discouraged, but simply killed. The end result is that
it cannot be used to accommodate external dependencies, and therefore
it might be a good idea to completely remove it from the system.

> Again, this is a reason why the usage is discouraged. I'm sure we'd
> be happy to include a patch to fix the issue if it doesn't create
> other issues as well (as your proposed change would, since it would
> also incorrectly prevent macports-provided ports from being upgraded
> if they were installed to satisfy a bin/lib style dependency).

I don't get this part: why would a portfile author use bin style if
his package solely depends on something in macports? One possibility
is that his package depends on one of two packages that provide the
same functionality, and if either one is installed, the dependency is
satisfied. However, correct me if I'm wrong, the current port
infrastructure does not seem to support such "or" dependency: in a bin
style declaration, only one package can be specified if the binary is
not present. This pretty much renders bin style useless.

> You could just remove the dependency from the portfile, if -n won't
> work for you and you're insistent on using an external dependency.

Actually that's my solution for gnuplot now. Personally I can live
with it; but I just think the macports should be more convenient to
use, especially for some users who do not want to understand
portfiles.

> Indeed, that's why (as I've said a few times now), the bin/lib style
> dependencies are discouraged in favor of port: style dependencies.

So... in the long run, none of the macport packages should depend on
any external programs/libraries? Is this already a consensus?

Best
Regards,

Xin Liu