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
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.
* Write a tcltk-update script that allows the user to switch tcl-tk versions
* Handle man pages and headers as mentioned in the original description for
* 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 attachment 21007 [details]
tk-8.4.4-r1 beta 1
Created attachment 21008 [details]
tcl-8.4.4-r1 beta 1