Magically-disappearing tclsh8.5

[Ryan Schmidt]

On Feb 24, 2013, at 13:58, Jim Graham wrote:
> On Sun, Feb 24, 2013 at 02:20:48PM -0500, Lawrence Velázquez wrote:
>> On Feb 24, 2013, at 1:03 PM, Jim Graham wrote:
>> 
>>> I had to re-install it, because it magically uninstalled itself, during,
>>> I suspect, the upgrade to the latest macports.
>> 
>> You mentioned that you upgraded to a new MacPorts base recently. Unless
>> you installed it from source, the install process automatically
>> performed a "port selfupdate", which would have updated your ports tree
>> to tcl @8.6.0.
> 
> That's fine.  But considering the fact that there are syntax changes
> between Tcl/Tk versions, removing an existing one is most definitely NOT
> safe, as it could break Tcl/Tk programs that the user has written.  I
> personally consider this extremely bad behavior.

MacPorts has no knowledge of what non-MacPorts files you have that might use MacPorts ports.

If you ask MacPorts to upgrade a port (or all outdated ports), that's what it's doing to do.

Yes, some things changed between tcl 8.5 and 8.6. Yes, this broke some ports. We had this same issue when tcl 8.4 was updated to 8.5. At the time it was suggested that we should make separate tcl84 and tcl85 ports, and such ports were even submitted and are attached to this trac ticket:

https://trac.macports.org/ticket/34826

But we decided instead to try to fix ports for tcl 8.5 compatibility, and that's what we've tried to do again with 8.6.

We can of course revisit this topic. The tricky part of offering multiple versioned ports is that they should be simultaneously installable, meaning the location where they install their files needs to be changed to include a version number, and that means every port using them needs to be updated to know about those changed paths as well. It's a big hassle that I for one would rather avoid if possible.


On Feb 24, 2013, at 15:03, Scott Webster wrote:

> There are lots of things that Macports COULD theoretically do, but
> given the available resources it basically only works in "one way."
> That means that there is one available version of every port, and

This is not always the case. There are multiple ports for php (php53, php54, php55, plus the legacy ones), python (python24, python25, python26, python27, python31, python32, python33), perl (perl5.8, perl5.10, perl5.12, perl5.14, perl5.16), etc. In the case of php and python this seems to work very well. Users can choose the version they want, ports can declare dependencies on the version they want, multiple versions can be installed at the same time. perl is supposed to work that way too, but there has been recent discussion about it not being worth the hassle and about undoing all of this and going back to just a single version of perl. So certainly before we invest energy in splitting tcl and tk into multiple versioned ports we should be sure that we really need that.


On Feb 24, 2013, at 15:50, Jim Graham wrote:

> I did the selfupdate for macports, and then port upgrade outdated.  And I
> have Tcl/Tk 8.5.x active.  It looks like none were removed---just
> deactivated, which actually is not even remotely as bad as removing
> them.  That is easily fixed by just activating the correct one.

Ok, so you did run "port upgrade" after all. So MacPorts did so. Only one version of a given port can be active at a time, so it will deactivate the old version when upgrading.

MacPorts won't uninstall ports unless you tell it to. You tell it to by either running "port uninstall", or by using the "-u" flag when upgrading. For example, if tcl is outdated, "sudo port -u upgrade tcl" would upgrade tcl and then uninstall the old one. If you want the old one to be deactivated instead of being uninstalled, you omit the "-u" flag.

Reinstalling old versions is possible: https://trac.macports.org/wiki/howto/InstallingOlderPort