Bug 1187230
| Summary: | [RFE] Wrap whole section is single "scl enable" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> |
| Component: | spec2scl | Assignee: | Iryna Shcherbina <ishcherb> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bkabrda, ishcherb, jberan, praiskup |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | spec2scl-1.2.0-2.fc25 spec2scl-1.2.0-2.fc24 spec2scl-1.2.0-2.fc26 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-04-27 19:51:50 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: | |
| Embargoed: | |||
|
Description
Vít Ondruch
2015-01-29 15:24:43 UTC
Makes perfect sense. Since Robert Kuska now takes care of spec2scl upstream, I'm assigning him. Robert, please consider implementing this. Can anybody elaborate in this bug report? Do we want to automatically wrap whole section without adding anything special related to %scl? Or does this proposal still require to have special wrapper macros? FWIW, I use this: http://copr-dist-git.fedorainfracloud.org/cgit/praiskup/rpm-config/scl-rpm-config.git/tree/macros.scl-helpers It is basically the same approach as mentioned in bug 1184515#c6, but a bit easier to write/read by human: %prep %{?scl_enable} wrapped commands %{?scl_disable} It is far from perfect though. It would be much nice to just write: %scl_prep wrapped commands Or just (when possible) %global auto_sclize # magic happens %prep wrapped commands So I'm just curious what should be the final outcome. (In reply to Pavel Raiskup from comment #3) > %prep > %{?scl_enable} > wrapped commands > %{?scl_disable} Something like this without the magic macros since IMHO (1) they hide too much (2) but you still have to write them. > Or just (when possible) > > %global auto_sclize # magic happens > > %prep > wrapped commands > This is of course "ideal" solution, but I am afraid it might make other things less transparent or even impossible. But as far as I understand RPM, it should be possible to change the "shell" or whatever executes the %prep and other sections, so in theory it should be achievable. (In reply to Vít Ondruch from comment #4) > Something like this without the magic macros since IMHO (1) they hide too > much (2) but you still have to write them. My POV, the benefit of hiding stuff is readability and the possibility to fix things (e.g my example is still missing 'set -e' command) at one place. Also it is hard to hide something for rpm -E. (In reply to Pavel Raiskup from comment #5) > My POV, the benefit of hiding stuff is readability and the possibility to fix > things (e.g my example is still missing 'set -e' command) at one place. Also > it is hard to hide something for rpm -E. I now realized this is spec2scl bugreport. Then my POV doesn't matter, users don't have to remember exact heredoc bash syntax, spec2scl does.. Something similar to %scl_enable would be a RFE against scl-utils-build I guess. I suggest not to use 'EOF' by default, though. That's sort of first-
choice to use by random package maintainer if he was about to
put shell heredoc directly into spec file. Recursive heredocs are
possible, as long as the end terminator differs:
scl enable autotools-git - <<BLAH
cat <<EOF
hello world
EOF
BLAH
Hi Pavel, spec2scl currently uses an approach documented in Packaging Guide [0] to convert scripts. Thanks for creating 1422625. When it is implemented I will make sure it is used in spec2scl. [0] https://www.softwarecollections.org/en/docs/guide/#sect-Converting_RPM_Scripts spec2scl-1.2.0-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb5158b47 spec2scl-1.2.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fa7ce0edff spec2scl-1.2.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-258e512e26 spec2scl-1.2.0-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb5158b47 spec2scl-1.2.0-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-258e512e26 spec2scl-1.2.0-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fa7ce0edff spec2scl-1.2.0-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. spec2scl-1.2.0-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. spec2scl-1.2.0-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. |