py-pygtk @2.22.0_4 returned: could not create new link

[nonstop.server@…]

Upgrading port py27-gtk from version 2.22.0_3 to 2.22.0_4 fails with error message:

Error: org.macports.destroot for port py27-pygtk returned: could not create new link "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-pygtk/py27-pygtk/work/destroot/opt/local/share/pygtk2.7" since target "../Library/Frameworks/Python.framework/Versions/2.7/share/pygtk" doesn't exist
Warning: targets not executed for py27-pygtk: org.macports.install org.macports.destroot
Error: Unable to upgrade port: 1

Version Information:

Mac OS Version:
ProductName:	Mac OS X
ProductVersion:	10.5.8
BuildVersion:	9L31a
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

Xcode Version:
Xcode 3.1.4
Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
BuildVersion: 9M2809

Macports Version:
Version: 2.1.2

[ryandesign (Ryan Carsten Schmidt)]

I remember the old Tcl on Leopard and earlier was picky about not wanting to create symlinks to things that didn't already exist. I think that was the problem with using "file link -symbolic". I see that the old pre-unification py27-gtk port used "system "ln -s"" instead, perhaps for that reason. I believe that was why we have the "ln -s" shortcut in MacPorts; it uses symlink(2) directly, bypassing the buggy implementation in old Tcls.

You can test whether this is the cause and solution by editing the py-pygtk portfile and changing occurrences of "file link -symbolic A B" to "ln -s B A". Note that the order of the arguments must be reversed. I'll test it myself in a moment, once my Leopard machine finishes what it's doing.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

You can test whether this is the cause and solution by editing the py-pygtk portfile and changing occurrences of "file link -symbolic A B" to "ln -s B A". Note that the order of the arguments must be reversed. I'll test it myself in a moment, once my Leopard machine finishes what it's doing.

Yes, this works. See attachment.

However, an even better solution is to use the ${python.prefix} variable, which is based on ${frameworks_dir}. Users are able to change frameworks_dir at MacPorts configure time; it does not necessarily have to be ${prefix}/Library/Frameworks so a relative symlink cannot be used. Fixed in r100357. Revision increased so that any users with non-default frameworks_dir will have a correct symlink.

[nonstop.server@…]

Replying to ryandesign@…:

Thank you for the quick solution, the port installs fine now.