Bug 705144
| Summary: | pymol packaging mishandles pymol_path | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Need Real Name <howarth> | ||||
| Component: | pymol | Assignee: | Tim Fenn <tim.fenn> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | tim.fenn | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | pymol-1.4.1-4.20110502svn3947.fc14 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-06-21 17:32:35 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
You won't notice the current breakage in pymol until you try to install something like relax nmr (http://www.nmr-relax.com/) which wants to load the pymol python module via the import mechanism. I discovered this problem in my MacPorts pymol/relax packaging where using Fedora'a approach of a pymol_path subdirectory instead of a symlink prevented relax from loading the pymol python module. I also notice that when pymol starts up it complains about not finding shader files. This is due to the incorrect usage of pymol_path which should be a symlink residing in {python_sitearch}/pymol that points at %{python_sitearch}/pymol. Currently it is a subdirectory in {python_sitearch}/pymol only contains a small fraction of the pymol files.
Created attachment 499372 [details]
proper use of pymol_path
The attached modified pymol.spec demonstrates the proper usage of pymol_path. Note that this packaging has issues upgrading from the current packaging due to the change of pymol_path from a directory to a symlink. Currently the existing pymol package must be deinstalled first. This needs to be addressed. However the attached packaging when installed allows pymol to be executed on the command line without any warning/error messages about the shader files not being found by pymol. Also note that the current mesa-dri support on radeon appears to be insufficient for proper shader support and this kernel panics the machine. I will open another PR about that. The horrible state of linux OpenGL driver support may be incapable of handling the shader support (which works fine on MacPorts/fink under MacOS X's Xquartz though).
Great, thanks for the updated specfile, Paul. I'll get a package into testing within the next day or so. I'll also bring the pymol_path issue up with upstream - this should be fixed properly. And I've had similar reports re. radeon drivers: https://bugzilla.redhat.com/show_bug.cgi?id=474652 test build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3077549 I changed: cp -pr data modules examples test scripts ${RPM_BUILD_ROOT}%{python_sitearch}/pymol to: cp -pr data examples test scripts ${RPM_BUILD_ROOT}%{python_sitearch}/pymol since the necessary modules are already installed (via setup.py), so they shouldn't need to be copied a second time, AFAICT. FYI, I tested my modified packaging on Fedora 14 against the non-free nvidia drivers and the shader support works fine there. pymol-1.4.1-2.20110502svn3947.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pymol-1.4.1-2.20110502svn3947.fc14 pymol-1.4.1-2.20110502svn3947.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pymol-1.4.1-2.20110502svn3947.fc15 pymol-1.4.1-3.20110502svn3947.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pymol-1.4.1-3.20110502svn3947.fc14 pymol-1.4.1-3.20110502svn3947.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pymol-1.4.1-3.20110502svn3947.fc15 (In reply to comment #3) > > Note that this packaging has issues upgrading from the current packaging due to > the change of pymol_path from a directory to a symlink. Currently the existing > pymol package must be deinstalled first. This needs to be addressed. I "fixed" this in 1.4.1-3 by using a %pre scriptlet: %pre if [ $1 -gt 1 ]; then rm -rf %{python_sitearch}/pymol/pymol_path fi Although there may be a more elegant solution? Package pymol-1.4.1-3.20110502svn3947.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pymol-1.4.1-3.20110502svn3947.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/pymol-1.4.1-3.20110502svn3947.fc14 then log in and leave karma (feedback). pymol-1.4.1-4.20110502svn3947.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pymol-1.4.1-4.20110502svn3947.fc14 pymol-1.4.1-4.20110502svn3947.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pymol-1.4.1-4.20110502svn3947.fc15 pymol-1.4.1-4.20110502svn3947.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. pymol-1.4.1-4.20110502svn3947.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: The current pymol 1.4.1-1.20110502svn3947 %{?dist} packaging mishandles the usage of pymol_path. The description of this feature in __init.py of pymol is confusing. The comments there say.... # NOTE: with both methods, you should be able to get away with not # specifying PYMOL_PATH if there is a subdirectory pymol_path located # in the "pymol" modules directory which points to the main # pymol directory This is nonsensical and really means to say that pymol_path should be a symlink residing in the pymol modules directory that points at the directory containing it. Thus the pymol package should be doing... ln -s %{python_sitearch}/pymol ${RPM_BUILD_ROOT}%{python_sitearch}/pymol/pymol_path Nothing needs to be 'copied' into pymol_path since it is just a symlink. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: