Fedora Account System
Red Hat Associate
Red Hat Customer
A prove of concept [1] I use for some time: %scl_enable() %{expand: \\\ scl enable %%{?scl} %%{?scl_build_scls} %%{?scl_package_build_scls} - \\\ <<'_SCL_EOF' \ set -xe} %scl_disable() _SCL_EOF This is to be used as: %prep %{?scl_enable} # Regular shell code. %{?scl_disable} The %{scl} is the actual collection being built, %scl_build_scls are colections which whole colection depends, and %scl_package_build_scls is to be set in particular SCL package spec file (when it is desired that we enable it only for that package). Note that the name doesn't matter, feel free to use some less general macro names. [1] http://copr-dist-git.fedorainfracloud.org/cgit/praiskup/rpm-config/scl-rpm-config.git/tree/macros.scl-helpers
Possibly we could have the terminator parametric, too: %scl_heredoc_terminator _SCL_EOF
Several notes: * Wouldn't be better to use parameters instead (or in parallel?) of the %scl_package_build_scls? * The order of listed collection matters. We take the last enabled SCL as a home for installation of currently build package, so the %%{?scl} should be the last. * Should (not) the macros end up by %{nil}?
(In reply to Vít Ondruch from comment #2) > so the %%{?scl} should be the last. Or may be the first, not sure now. Would need to check that, sorry ;) Can't find the right example now :(
(In reply to Vít Ondruch from comment #2) > Several notes: > > * Wouldn't be better to use parameters instead (or in parallel?) of the > %scl_package_build_scls? Perhaps there could be both, sounds like a good idea. > * The order of listed collection matters. We take the last enabled SCL as a > home for installation of currently build package, so the %%{?scl} should be > the last. Correct. We want %scl to have the highest priority. > * Should (not) the macros end up by %{nil}? Dunno, should they? I haven't had issues with those macros so far, but definitely I could be missing something. Thanks for the review! That macros should still stay "opt-in" IMO, no strict guidelines for packagers -- so if we don't cover completely every use-case out there, it is fine. Let me know whether it makes sense to update the proposal.
(In reply to Pavel Raiskup from comment #4) > (In reply to Vít Ondruch from comment #2) > > * Should (not) the macros end up by %{nil}? > > Dunno, should they? I haven't had issues with those macros so far, but > definitely I could be missing something. AFAIK the difference will be what happens if you write something like: ~~~ %{?scl_enable} something right behind the macro ~~~ This will expand to: ~~~ set -xe something right behind the macro ~~~ Which might be useful/harmful, depends how it is used. If you end the macro by %{nil} there is new line inserted after the %{nil}. I'm raising this question based on my experience with bug 1121649.
Agreed, <newline>%nil (newline is crucial) makes sense.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Package in survival mode, no new features planned