Hide Forgot
Description of problem: I'm receiving the following error when building RPM: # rpmbuild -ba my.spec py3_install: invalid option -- '-' error: /code/my.spec: line 35: Unknown option - in py3_install() Here's the %py_install line from my %install: %install %py3_install --install-scripts %{_libexecdir} The only way I can make this work is by using: %install %py3_install -- --install-scripts %{_libexecdir} Version-Release number of selected component (if applicable): # rpm -qa rpm-build python3-devel rpm-build-4.15.1-1.fc31.x86_64 python3-devel-3.7.6-2.fc31.x86_64 Expected results: I wouldn't expect to have to use the `--` to delimit flags from %py3_install.
These are parametric macros (from python-rpm-macros), so rpm will treat anything starting with a dash as a *macro* option, unless separated with --. Looking at these macros, they don't actually take any options so don't know why there are declared as such. Non-parametric might be better-suited to task at hand: these are just thinly veiled calls to python setup.py <foo>, and people expect arbitrary arguments to be passed on verbatim. As is the case here.
Panu, can non-parametric macros accept positional arguments? We do have %{?*} in there. This is unlikely to change anyway. 1) The macros need to preserve backwards compatibility. 2) We are working on new macros instead: https://src.fedoraproject.org/rpms/pyproject-rpm-macros Robert, using -- to separate the arguments is a known thing. We might want to say that in the guidelines thou, so I keep this open.
> Panu, can non-parametric macros accept positional arguments? We do have %{?*} in there. Non-parametric macros don't *have* arguments, they're just ... text. So if you're just adding adding %{?*} at the end a parametric macro is little else than jumping through a whole bunch of hoops for nothing. %py3_install() %{expand:\\\ CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\ %{__python3} %{py_setup} %{?py_setup_args} install -O1 --skip-build --root %{buildroot} %{?*} } %py3_install %{expand:\\\ CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\ %{__python3} %{py_setup} %{?py_setup_args} install -O1 --skip-build --root %{buildroot} } ...for most practical purposes do the same exact thing, only the former means you can't pass arbitrary options to setup.py install without --. Which might be all well and good, "arbitrary" can be a double-edged sword. I'm not saying you *should* change these, but it's something you want to be aware of at least.
I see, thanks for the explanation. The biggest problem with that approach is that the arguments would be passed to rm: %py3_install() %{expand:\\\ CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\ %{__python3} %{py_setup} %{?py_setup_args} install -O1 --skip-build --root %{buildroot} %{?*} rm -rfv %{buildroot}%{_bindir}/__pycache__ } Or to sleep: %py2_build() %{expand:\\\ sleep 1 CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\ %{__python2} %{py_setup} %{?py_setup_args} build --executable="%{__python2} %{py2_shbang_opts}" %{?*} sleep 1 } Etc. (the macros take arguments, so we can put them where we need them). We could possibly replace this with a clever shell function, but as said, we won't do this for the 2 listed reasons.
Yup, having control of arguments of course opens possibilities that don't exist otherwise. In these cases having to use -- might well be only a good thing. Just FYI, there's a related upstream ticket requesting more control to macros over their options processing: https://github.com/rpm-software-management/rpm/issues/547
+1 to https://github.com/rpm-software-management/rpm/issues/547 Anyway, back to the topic: https://pagure.io/packaging-committee/pull-request/962
This is now documented in https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros