Dependency Problem of Upgrading Gnuplot: A Possible Bug

[Xin Liu]

On 7/25/07, Daniel J. Luke <dluke at geeklair.net> wrote:
> On Jul 24, 2007, at 7:32 PM, Xin Liu wrote:
> > 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?
>
> yes, but it can be solved by changing the portfile (and perhaps
> adding a MacTex portfile?)

The inconsistence between "install" and "upgrade" is an infrastructure
problem. Manipulating portfiles is just a temporary hack, and it does
not solve the real problem.

Fine, we can add a portfile for MacTeX. But the binary is readily
available there; how many users are willing to spend the time and CPU
compiling it? How about users out there that want to use teTeX? One
side will be pissed off, because whenever they upgrade gnuplot, one
tex system that they do not like will be forced to install on their
systems, and the other tex system cannot co-exist because they simply
provide conflicting binaries.

> You didn't waste your time, it's just that your suggested fix causes
> other problems. If you can think of a better way to do it, I'm sure
> Macports would be happy to incorporate your changes.

I suggest that "upgrade" do not touch bin/lib style dependencies. What
problem does this fix cause? You said that this will cause problem for
portfiles that use bin/lib style to refer to internal dependencies,
but that's their authors' fault: they should not use bin/lib style
this way (and I highly suspect any portfile author will do this). Or
is there any concrete example that a portfile has to use bin/lib style
for internal dependencies?