Pymol destroot fails

[josh.baraban@…]

The pymol destroot stage fails, apparently because it creates a file in the destroot directory and then attempts to copy over it.

Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists

I tried cleaning, and also deleting the offending file manually, but the destroot stage of the port, which I ran individually, creates it and then throws an error because of it.

[josh.baraban@…]

main.log

[ryandesign (Ryan Carsten Schmidt)]

It looks like you're running trace mode? Does the problem go away if you don't use trace mode?

[josh.baraban@…]

No, I tried trace mode because the macports website recommended trying that before submitting a ticket. Same problem without trace mode. Thanks, Josh

[itamar.kass@…]

I have the same problem in the last few days.

IK

port install pymol

attachment:main.log.bz2​

[mamoll (Mark Moll)]

Cc Me!

[michelle.lynn.gill@…]

Cc Me!

[josh.baraban@…]

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[mtiberti (Matteo Tiberti)]

Weirdly enough, that doesn't seem to be working for me; I have modified the portfile found in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol as you suggested:

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

$ tail Portfile
}

post-destroot {}
post-destroot {
     # file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
     # file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
     foreach d {data modules examples test scripts} {
        copy ${worksrcpath}/${d} ${destroot}${python.pkgd}/pymol
    }
 }

$ sudo port clean pymol; sudo port install pymol
--->  Cleaning pymol
--->  Computing dependencies for pymol
--->  Fetching archive for pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/pymol
--->  Fetching distfiles for pymol
--->  Verifying checksums for pymol
--->  Extracting pymol
--->  Applying patches to pymol
--->  Configuring pymol
--->  Building pymol
--->  Staging pymol into destroot
Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists
Please see the log file for port pymol for details:
    /opt/local/var/macports/logs/_Users_matteotiberti_devel_ports_science_pymol/pymol/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pymol failed

Replying to josh.baraban@…:

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[josh.baraban@…]

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Replying to matteo.tiberti@…:

Weirdly enough, that doesn't seem to be working for me; I have modified the portfile found in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol as you suggested:

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

$ tail Portfile
}

post-destroot {}
post-destroot {
     # file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
     # file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
     foreach d {data modules examples test scripts} {
        copy ${worksrcpath}/${d} ${destroot}${python.pkgd}/pymol
    }
 }

$ sudo port clean pymol; sudo port install pymol
--->  Cleaning pymol
--->  Computing dependencies for pymol
--->  Fetching archive for pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/pymol
--->  Fetching distfiles for pymol
--->  Verifying checksums for pymol
--->  Extracting pymol
--->  Applying patches to pymol
--->  Configuring pymol
--->  Building pymol
--->  Staging pymol into destroot
Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists
Please see the log file for port pymol for details:
    /opt/local/var/macports/logs/_Users_matteotiberti_devel_ports_science_pymol/pymol/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pymol failed

Replying to josh.baraban@…:

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[mtiberti (Matteo Tiberti)]

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Replying to josh.baraban@…:

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Replying to matteo.tiberti@…:

Weirdly enough, that doesn't seem to be working for me; I have modified the portfile found in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol as you suggested:

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

$ tail Portfile
}

post-destroot {}
post-destroot {
     # file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
     # file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
     foreach d {data modules examples test scripts} {
        copy ${worksrcpath}/${d} ${destroot}${python.pkgd}/pymol
    }
 }

$ sudo port clean pymol; sudo port install pymol
--->  Cleaning pymol
--->  Computing dependencies for pymol
--->  Fetching archive for pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/pymol
--->  Fetching distfiles for pymol
--->  Verifying checksums for pymol
--->  Extracting pymol
--->  Applying patches to pymol
--->  Configuring pymol
--->  Building pymol
--->  Staging pymol into destroot
Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists
Please see the log file for port pymol for details:
    /opt/local/var/macports/logs/_Users_matteotiberti_devel_ports_science_pymol/pymol/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pymol failed

Replying to josh.baraban@…:

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[josh.baraban@…]

Modified Portfile

[josh.baraban@…]

I just attached the modified Portfile, and it's in the usual place on my system: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

Replying to matteo.tiberti@…:

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Replying to josh.baraban@…:

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Replying to matteo.tiberti@…:

Weirdly enough, that doesn't seem to be working for me; I have modified the portfile found in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol as you suggested:

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

$ tail Portfile
}

post-destroot {}
post-destroot {
     # file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
     # file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
     foreach d {data modules examples test scripts} {
        copy ${worksrcpath}/${d} ${destroot}${python.pkgd}/pymol
    }
 }

$ sudo port clean pymol; sudo port install pymol
--->  Cleaning pymol
--->  Computing dependencies for pymol
--->  Fetching archive for pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/pymol
--->  Fetching distfiles for pymol
--->  Verifying checksums for pymol
--->  Extracting pymol
--->  Applying patches to pymol
--->  Configuring pymol
--->  Building pymol
--->  Staging pymol into destroot
Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists
Please see the log file for port pymol for details:
    /opt/local/var/macports/logs/_Users_matteotiberti_devel_ports_science_pymol/pymol/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pymol failed

Replying to josh.baraban@…:

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[mtiberti (Matteo Tiberti)]

Thanks! It gives the same error nonetheless on my system... weird stuff. :(

Replying to josh.baraban@…:

I just attached the modified Portfile, and it's in the usual place on my system: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

Replying to matteo.tiberti@…:

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Replying to josh.baraban@…:

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Replying to matteo.tiberti@…:

Weirdly enough, that doesn't seem to be working for me; I have modified the portfile found in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol as you suggested:

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/pymol

$ tail Portfile
}

post-destroot {}
post-destroot {
     # file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
     # file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
     foreach d {data modules examples test scripts} {
        copy ${worksrcpath}/${d} ${destroot}${python.pkgd}/pymol
    }
 }

$ sudo port clean pymol; sudo port install pymol
--->  Cleaning pymol
--->  Computing dependencies for pymol
--->  Fetching archive for pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://lil.fr.packages.macports.org/pymol
--->  Attempting to fetch pymol-1.7.1.0_0.darwin_14.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/pymol
--->  Fetching distfiles for pymol
--->  Verifying checksums for pymol
--->  Extracting pymol
--->  Applying patches to pymol
--->  Configuring pymol
--->  Building pymol
--->  Staging pymol into destroot
Error: org.macports.destroot for port pymol returned: error copying "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/pymol/setup/pymol_macports" to "/opt/local/var/macports/build/_Users_matteotiberti_devel_ports_science_pymol/pymol/work/destroot/opt/local/bin/pymol": file already exists
Please see the log file for port pymol for details:
    /opt/local/var/macports/logs/_Users_matteotiberti_devel_ports_science_pymol/pymol/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port pymol failed

Replying to josh.baraban@…:

So, I'm sure this is not an ideal solution, but commenting out the first two lines of the destroot section in the Portfile, e.g.:

#     file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
#     file attributes ${destroot}${prefix}/bin/pymol -permissions a+x

appears to fix the problem. pymol installs and runs normally, as far as I can tell.

[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.

--- Portfile.orig	2014-10-31 16:25:18.000000000 -0400
+++ Portfile	2014-10-31 16:05:58.000000000 -0400
@@ -7,7 +7,7 @@
 
 name                pymol
 version             1.7.1.1
-revision            1
+revision            2
 categories          science chemistry
 license             GPL
 maintainers         bromo.med.uc.edu:howarth
@@ -103,6 +103,7 @@
 }
 
 post-destroot {
+     file delete ${destroot}${prefix}/bin/pymol
      file copy ${worksrcpath}/setup/pymol_macports ${destroot}${prefix}/bin/pymol
      file attributes ${destroot}${prefix}/bin/pymol -permissions a+x
      foreach d {data modules examples test scripts} {

Of course, the most annoying bug of all in pymol is how utterly useless the "require_active_variants" field is. From a clean install of MacPorts on Yosemite, with the first install being "sudo port -d install pymol", port totally ignores the lines...

require_active_variants tcl "" corefoundation
require_active_variants tk "" quartz

which should be preselecting the appropriate tcl and tk variants. You have to manually execute...

sudo port -d install tcl -corefoundation
sudo port -d install tk -quartz

to unbreak the installed pymol.

[SickTeddyBear]

Cc Me!

[teige-mp@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

itamar.kass's main.log file

[ryandesign (Ryan Carsten Schmidt)]

Replying to itamar.kass@…:

I have the same problem in the last few days.

Please don't paste enormous output into a ticket comment; attach it instead. I have removed the log from your comment and attached it as an attachment.

[petrrr]

Cc Me!

[p-bro]

Cc Me!

[Lenuci@…]

Same problem :-((

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.

[josh.baraban@…]

Thanks for tracking that down.

Replying to ryandesign@…:

Replying to 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.

[miguelr@…]

Cc Me!

[miguelr@…]

Cc Me!