Bug 1818920

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