Dependency Problem of Upgrading Gnuplot: A Possible Bug

[Xin Liu]

> > At least, "install" and "upgrade" should be consistent.
>
> They aren't because they do different things.

A user is simply confused if they are inconsistent. For instance, when
the guy invokes "install" for gnuplot (and he has MacTex installed),
he is relaxed to find that no extra tex system is installed. However,
when later a newer version of gnuplot is available and he invokes
"upgrade", he suddenly finds that an additional tex system is
installed! Isn't this a bad user experience caused by the
inconsistence? At least I didn't feel good, and I reported this as a
bug and spent time looking into the source code only to discover that
this is a "feature" and I kind of wasted my time.

As to the solution for the problem, it really depends on the attitude
towards external dependencies. I'd suggest (maybe these are completely
wrong, because I haven't read through previous discussions and may
miss a lot of points):

1. If ultimately the external dependencies will be removed completely,
"install" command should treat bin/lib style dependencies the same way
as "upgrade" command, and portfile authors should be advised not to
introduce any external dependencies using bin/lib style.

2. If external dependencies are still desirable and will be supported
by the system, more explicit dependency styles such as
external_bin/external_lib should be introduced, and "update" command
should not touch them at all.

In either case, I strongly suggest "install" and "upgrade" be
consistent. As for the "all-in-macports" philosophy... I don't think
I'm persuasive enough to change it :-(, and I'll just maintain my own
local port repository to live with it...