Macports Tcl

[Lawrence Velázquez]

On Jul 13, 2013, at 1:11 PM, Gustaf Neumann <neumann at wu.ac.at> wrote:

> not sure, i understand correctly. If you suggest to run port
> itself on its own port, this can be dangerous:
> - a user might deinstall tcl and that would kill ports alltogether

The MacPorts port would explicitly depend on tcl. Removing tcl would then require "sudo port -f uninstall tcl", and that's as unsupported as "sudo rm -fR /opt/local/libexec/macports/tcl" would be.

> - if someone installs a broken tcl-port, everything will be broken.

If MacPorts' build system happens to pull down a broken Tcl from upstream, everything will be broken. Updates for a bundled Tcl would have to be tested regardless, whether delivered via a port update or via the build system.

> - the tcl port is currently just called "tcl" (not tcl84, tcl85 or tcl86),
>  so the macports team has verly little control, what version
>  of tcl is being used.

Creating ports for each version would not be particularly difficult.

> - tcl has variants. The user variant which might or might
>  not be the same as the one that macports has..

Does MacPorts care whether Tcl has support for CoreFoundation, multithreading, or memory debugging? The Tcl ports could default to including whatever features MacPorts requires.

> There are probably many more such reasons.

Probably, but it's good to flesh out the concerns.

> Having an own, separate copy for macports and nobody else
> seems to me pretty robust.

This is really the only short-term bundling solution, in any case. MacPorts self-management won't happen for a while, if ever.

vq