[MacPorts] #45401: Pymol destroot fails

[MacPorts]

#45401: Pymol destroot fails
-----------------------------+-----------------------------------
  Reporter:  josh.baraban@…  |      Owner:  howarth.at.macports@…
      Type:  defect          |     Status:  closed
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.3.1
Resolution:  fixed           |   Keywords:
      Port:  pymol           |
-----------------------------+-----------------------------------
Changes (by ryandesign@…):

 * cc: ryandesign@… (added)
 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:13 jhowarth@…]:
 > For some reason port has regressed such that when it begins to execute
 the post-destroot the following symlink has already been errorenously
 created...
 >
 > {{{
 > % ls -l
 "/opt/local/var/macports/build/_Users_howarth_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol"
 > lrwxr-xr-x  1 root  admin  69 Oct 31 16:02
 /opt/local/var/macports/build/_Users_howarth_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol
 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pymol
 > }}}
 >
 > So apply the ugly hack below will purge it until we discover why port is
 misbehaving.

 The reason for the destroot failure is a change that was made to the
 python 1.0 portgroup in r126798. That this change caused a destroot
 failure in pymol does not indicate a regression of the python 1.0
 portgroup, but rather that pymol is not using a directive it should be
 using to disable this particular functionality of the python 1.0
 portgroup. Pymol should probably have been using this directive all along,
 it just didn't result in a destroot failure until this change.

 Ports using the python 1.0 portgroup install their files into deep
 directories within ${frameworks_dir}/Python.framework. This is
 inconvenient for users who want to run programs that those ports install.
 For this reason, when using python 2.6 or later, the python 1.0 portgroup
 by default creates symlinks to those programs and places them in
 ${prefix}/bin. Ports that do not want this behavior can set
 "`python.link_binaries no`".

 Python module ports—those whose names begin with "py-", which install
 python modules that other programs written in python will use—usually have
 subports for multiple versions of python each, for example for 2.7 and
 3.4. We want the user to be able to install these simultaneously, which
 would not be possible if they each installed the same files in the same
 locations. For this reason, when using python 2.6 or later, the python 1.0
 portgroup by default appends a versioned suffix to the name of each
 symlink. Ports that do not want this behavior can set
 "`python.link_binaries_suffix`" to a different value, including the empty
 string if no suffix is desired.

 Python application ports—those whose names do not begin with "py-", which
 install programs the user is expected to use directly, and which do not
 install modules usable by other python software—do not have subports and
 are only available for a specific version of python. Python application
 ports were previously expected to manually set
 "`python.link_binaries_suffix`" to the empty string. r126798 changes the
 python 1.0 portgroup to make that happen automatically.

 Pymol is unusual in that it installs a wrapper script that users are
 expected to run. But the pymol port does not modify the default values of
 `python.link_binaries` or `python.link_binaries_suffix`. So prior to this
 change, an unwanted and unneeded symlink ${prefix}/bin/pymol-2.7 was being
 created which users were expected to ignore, and in addition the port was
 installing its own wrapper script at ${prefix}/bin/pymol which users were
 expected to use. After this change, the unwanted and unneeded symlink is
 being installed at ${prefix}/bin/pymol, thus preventing the pymol wrapper
 script from being installed there.

 If the wrapper script is needed, then the solution is to instruct the
 python 1.0 portgroup to not create the symlink, by setting
 "`python.link_binaries no`". I have committed this change in r129465
 because it matches the behavior of Jack's patch in comment:13 and #45721.

 If the wrapper script is not needed, then the solution is to remove the
 wrapper script. Jack suggested this in #46218 so we can explore that
 option more there.

-- 
Ticket URL: <https://trac.macports.org/ticket/45401#comment:20>
MacPorts <https://www.macports.org/>
Ports system for OS X