| Summary: | RFE: enhance %py[2,3]_install | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | python-rpm-macros | Assignee: | Orion Poplawski <orion> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | j, mhroncok, orion |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-12-19 18:58:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
It's not a bad idea and indeed I'd like to do as much of this magic as possible because packagers really shouldn't have to care. However, I'm concerned about the possibility of breakage. I could quickly whip something up but then it would take some mass rebuilding to ensure that nothing breaks. Do you have a number of packages that could be used for testing? I would also build in a macro you'd set to disable the magic if necessary. I'd prefer not to have to use line noise to turn it on. (In reply to Jason Tibbitts from comment #1) > It's not a bad idea and indeed I'd like to do as much of this magic as > possible because packagers really shouldn't have to care. However, I'm > concerned about the possibility of breakage. > > I could quickly whip something up but then it would take some mass > rebuilding to ensure that nothing breaks. > > Do you have a number of packages that could be used for testing? Yeah, I have a few, and would be willing to test. Actually, a second thought. Presently few packages uyse %py[2,3] install, so wouldn't benefit from this. I wonder if in the sort term it wouldn't be better to have a macro %py[2,3]_postinstallfixup that did those various operations. Then folks could opt into that as they wish. And then, in the fullness of time, perhaps they could move to %py[2,3]_install. That would mitigate your concerns about breakage? so, I image something like... %install %py3_install %py3_postinstallfixups %py2_install %py2_postinstallfixups Actually I'd really want the new fancy macros to just handle all of that, which gives people an incentive to switch. However, there's no reason it can't live in a separately accessible macro as well. The fact that there aren't too many packages which use the newest macros currently does make it easier to make sure we aren't breaking anything, though. I just need to block out some time to mess with this. Also, uh, just say no to two extra lines of bizarre macros people have to use. Some comments: - Many of these things should be reported/fixed upstream. Hopefully this won't just hide all of that. - I know ansible uses shbangs for a purpose in the installed code, so it definitely needs to be able to be disabled. It definitely possible to output useful warnings when something needs to be fixed up. But really, upstreams generally don't care. I'd be surprised if ansible did this in a way that conflicts with this, and if it did then I'd argue that it's doing something wrong. Does rpmlint currently complain about shebanged and not executable files directly in the python module directories? For ansible: https://bugzilla.redhat.com/show_bug.cgi?id=1272193 Wow, unless I'm missing something, that's bad packaging. The files in question are data. They shouldn't be in python_sitelib. They should be in /usr/share/ansible somewhere. This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. We are working on https://src.fedoraproject.org/rpms/pyproject-rpm-macros to replace %py[2,3]_install. There will be no enhancement of the old macros. |
Description of problem: Two very common things I end up doing in spec files after the install command are: 1) Fixing up permissions on any .so compiled python extensions to have perms 755 - often they're 775 or some other permission. 2) Replacing #!/usr/bin/env blah style shebangs to explicitly call python2[,3] Both of these actions actually could and should be done for all packages automatically by during the %py[2,3]_install macros, I think. 3) Removing shebangs from python files in the site-packages directory Some examples of the sorts of things I often see in spec files: find %{buildroot}%{python2_sitearch}/OpenGL_accelerate/ -name *.so -exec chmod 755 '{}' \; find %{buildroot}%{python3_sitearch}/OpenGL_accelerate/ -name *.so -exec chmod 755 '{}' \; find -name '*.py' | xargs sed -i '1s|^#!.*python|#!%{__python}|' etc ettc