Hi Jan, thanks for the answer. On 13.10.17 14:04 jan matejek wrote:
hello, as for the errors you're seeing, I vaguely recall that these are the correct errors... You can in theory remove alternatives in %preun or in %postun and both produce an error because both RPM and alternatives are removing the same file. %postun is the correct place for a different reason, but you still get the alternative error because the files it's looking at are already removed.
OK, good to know.
Other than that, you're not doing it entirely right. Which most likely means the chardet package from which you took it should be fixed as well.
You know that better than me. ;-)
1. instead of %python_expand over python_install, you should use %python_clone. like this:
%python_install %python_clone -a %{buildroot}%{_bindir}/redfish-client
%python_clone takes the named binary and makes appropriate copies to redfish-client-2.7, -3.6, etc. The -a option will include the %prepare_alternative, because that is a common usecase. So you can leave out %prepare_alternative as well.
Nice, will add that.
2. You're installing two separate alternative groups. Users would select separate version for redfish-client and redfish-check-cartridge. Usually not what you want. Put it into a single call:
%python_install_alternative redfish-client redfish-check-cartridge
Ah, I did not know that works. Nice.
On the uninstall side, use only the first argument:
%python_uninstall_alternative redfish-client
OK.
3. Do you actually _need_ alternatives here? Does it make sense for the user to choose which python to use for redfish-client (and check-cartridge)? If not, I suggest removing the alternatives entirely, and marking the binaries for python3 in the filelist:
I thought the whole point of alternatives was to give the user the possibility to either install the python2-based or the python3-based package. And either way the binary to use is called redfish-client. So yes, I think I need the alternatives.
(4. aside: in order to run nosetests in %check, do: %python_exec -m nose or: %python_exec /usr/bin/nosetests or: %python_expand nosetests-%{$python_bin_suffix} )
5. Most likely, you don't need all versions of Sphinx to build, uh, the manpage only? use BuildRequires: python3-Sphinx instead of %python_module Sphinx (and same for other packages that are only needed for docs)
Thanks for the hint, basically I am just beginning to get the grope with python packaging. So, I was not sure if python3-sphinx was needed for python3-redfish and the same for python2. But good to know only one version is enough.
6. For your second question, yes, making a common subpackage this way is a valid approach. However, the "Requires: %{name}-common" doesn't do what you think. This way python2-redfish requires python2-redfish-common and similarly with python3. To fix this, add "Provides: %{python_module redfish-common = %{version}}" to the common subpackage.
I must have misread the singlespec docs, I thought using %name-common for the subpackage would lead to it not being touched by singlespec. So there would be only one python-redfish-common package... ;-(
that's about it, i guess :)
Thanks a lot for the detailed answer, I will try to follow your advice, once OBS is working again. Johannes