Bugzilla Bug 4450

Although I can find no convention on this, it would seem tcl.h should probably
be placed in /usr/include/tcl8.3, and tk.h in /usr/include/tk8.3.  Debian puts
them both in /usr/include/tcl8.3, but either way will save major headaches when
tcl/tk 8.4 is released.

Also the api to tcl/tk changes frequently, we need to provide a mechanism to
have the developer choose the version of tcl/tk headers to include.  We could
possibly place a symlink from /usr/include/tcl8.3/tcl.h to /usr/include/tcl.h to
provide backward compatibility, as well as in the future provide a mechanism for
a default tcl.h header.  Same goes for tk.  Right now, there is no way to
install tcl/tk 8.1 on my system without breaking tck/tk 8.3 other than
installing in /usr/local/include.

tcl and tk are sep packages thus they get sep dirs ... i find the way it is 
currently setup to be the 'norm' on distro's ive used

Good suggestion, but as we only have one version of tcl, it's not a problem
right now. Whenever 8.4 comes out and we get a package for it, we'll handle it
then. 

8.4 is out and a lot of people who want to use it find it's breaking other 
packages (which explains why it's still masked). I've written a couple of beta 
ebuilds for slotted tcl and tk. This will allow everybody to keep the old 
libraries for backward-compatability, and still take advantage of the new 
features in the language.

TODO: 
* Write a tcltk-update script that allows the user to switch tcl-tk versions
(see opengl-update).
* Handle man pages and headers as mentioned in the original description for
this bug.
* Clean up this hack, possibly using tcltk-update to check for previously 
installed versions and create symlinks (and possibly move this functionality 
from src_install to pkg_postinst).

I'm still new to writing ebuilds, so there's probably much more room for improvement. 

Created an attachment (id=21007) [details]
tk-8.4.4-r1 beta 1

Created an attachment (id=21008) [details]
tcl-8.4.4-r1 beta 1