Opened 3 years ago

Closed 3 years ago

Last modified 17 months ago

#45401 closed defect (fixed)

Pymol destroot fails

Reported by: josh.baraban@… Owned by: howarth.at.macports@…
Priority: Normal Milestone:
Component: ports Version: 2.3.1
Keywords: Cc: mamoll (Mark Moll), michelle.lynn.gill@…, matteo.tiberti@…, iaindhay@…, SickTeddyBear, teige-mp@…, itamar.kass@…, petrrr, p-bro, ryandesign (Ryan Schmidt)
Port: pymol

Description (last modified by ryandesign (Ryan Schmidt))

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.

Attachments (4)

main.log (592.2 KB) - added by josh.baraban@… 3 years ago.
main.log
Portfile (3.9 KB) - added by josh.baraban@… 3 years ago.
Modified Portfile
main.log.bz2 (23.8 KB) - added by ryandesign (Ryan Schmidt) 3 years ago.
itamar.kass's main.log file
main.2.log (559.2 KB) - added by Lenuci@… 3 years ago.
Same problem :-((

Download all attachments as: .zip

Change History (27)

Changed 3 years ago by josh.baraban@…

main.log

comment:1 Changed 3 years ago by ryandesign (Ryan Schmidt)

  • Description modified (diff)
  • Owner changed from macports-tickets@… to howarth@…

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

comment:2 Changed 3 years ago by 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

comment:3 follow-up: Changed 3 years ago by itamar.kass@…

I have the same problem in the last few days.

IK

port install pymol

attachment:main.log.bz2

Last edited 3 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:4 Changed 3 years ago by mamoll (Mark Moll)

  • Cc mmoll@… added

Cc Me!

comment:5 Changed 3 years ago by michelle.lynn.gill@…

  • Cc michelle.lynn.gill@… added

Cc Me!

comment:6 follow-up: Changed 3 years ago by 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.

comment:7 Changed 3 years ago by larryv (Lawrence Velázquez)

  • Cc matteo.tiberti@… iaindhay@… added

comment:8 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by 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.

Last edited 3 years ago by matteo.tiberti@… (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by 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.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 3 years ago by 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.

Changed 3 years ago by josh.baraban@…

Modified Portfile

comment:11 in reply to: ↑ 10 ; follow-up: Changed 3 years ago by 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.

comment:12 in reply to: ↑ 11 Changed 3 years ago by 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.

comment:13 follow-up: Changed 3 years ago by 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.

Last edited 3 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:14 Changed 3 years ago by SickTeddyBear

  • Cc amcgee@… added

Cc Me!

comment:15 Changed 3 years ago by teige-mp@…

  • Cc teige-mp@… added

Cc Me!

Changed 3 years ago by ryandesign (Ryan Schmidt)

itamar.kass's main.log file

comment:16 in reply to: ↑ 3 Changed 3 years ago by ryandesign (Ryan Schmidt)

  • Cc itamar.kass@… added

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.

comment:17 Changed 3 years ago by petrrr

  • Cc petr@… added

Cc Me!

comment:18 Changed 3 years ago by petrrr

  • Owner changed from howarth@… to howarth.at.macports@…

comment:19 Changed 3 years ago by p-bro

  • Cc p.bro@… added

Cc Me!

Changed 3 years ago by Lenuci@…

Same problem :-((

comment:20 in reply to: ↑ 13 ; follow-up: Changed 3 years ago by ryandesign (Ryan Schmidt)

  • Cc ryandesign@… added
  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:21 in reply to: ↑ 20 Changed 3 years ago by 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.

comment:22 Changed 17 months ago by miguelr@…

  • Cc miguelr@… added

Cc Me!

comment:23 Changed 17 months ago by miguelr@…

  • Cc miguelr@… removed

Cc Me!

Note: See TracTickets for help on using tickets.