On 13 Oct 1999, Michael Graff wrote:

> Christoph Badura <bad@oreilly.de> writes:
> > Personally, I don't see why I should have to upgrade postgresql just
> > because tcl got upgraded.
> 
> I'm not concerned about postgresql, I was just using that as an
> example.  Besides, postgresql uses ncurses, libreadline, and other
> things that will get upgraded from time to time I suspect.

In contrast with perl, there's everything reason to think that scripts
that work with tcl-8.0.5 will still work with tcl-9.X.X So when tcl is
updated, a wildcard depends would be appropriate. As for the others,
the question has to answered case by case.
 
> So, what should I do about lame and gtk+ GUI bits?
> 
> I didn't split them, since I don't want to have to install one as
> "lame" and another as "lame-gui" -- that's just, well, lame.  And if I
> choose to split them and make them conflict with one another as I had
> before, I cannot build both with "cd audio ; make install" anymore
> anyway.  So, which is the default?  And if there is a default, why not
> have just one with build options?

converters/{uulib,uudeview,xdeview} sets an interesting precedent.
They're all built from the same distribution, but uulib is only the
library. uudeview is built without Tcl, and only depends on uulib.
xdeview only installs the Tcl and Tk stuff, it depends on uulib, too,
but it neither depends on, nor conflicts with uudeview.

I intend to do something similar with sysutils/hfsutils, except that
I'm inclined to include the Tcl shell with the command line tools,
which it is, and only seperate out the Tk gui.