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. 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. 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. 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 On the uninstall side, use only the first argument: %python_uninstall_alternative redfish-client 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: %python3_only %{_bindir}/redfish-client If you don't need alternatives but want to retain the binaries in a python2 package too, you can use %python_clone without the "-a" option, and then use a filelist like this: %{_bindir}/redfish-client-%{python_bin_suffix} %python3_only %{_bindir}/redfish-client That way redfish-client-2.7 will be available in python2 and -3.6 in python3, but the unversioned name only in python3. (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) 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. that's about it, i guess :) regards m. On 13.10.2017 11:12, Johannes Kastl wrote:

Dear python-experts,

I wanted to play around with python-redfish, so I started to package it. mnhauke already had a package, which I took as a starting point and tried to convert to singlespec.

home:ojkastl_buildservice:Redfish_openSUSE

2 questions:

###

I copied the update-alternative stuff from another spec (I think python-chardet), and it seems to build, but this is in the logs.

Am I missing something in the spec? Error in the mv commands (mv /usr/bin/redfish-client /usr/bin/redfish-client-2.7 etc.)? Conditional missing?

...

[ 71s] (order: reverse python-redfish-common python2-redfish python3-redfish) [ 71s] update-alternatives: error: alternative path /usr/bin/redfish-client-2.7 doesn't exist [ 71s] update-alternatives: error: alternative path /usr/bin/redfish-check-cartridge-2.7 doesn't exist [ 71s] warning: %postun(python2-redfish-0.4.1-3.1.noarch) scriptlet failed, exit status 2 [ 71s] update-alternatives: error: alternative path /usr/bin/redfish-client-3.6 doesn't exist [ 71s] update-alternatives: error: alternative path /usr/bin/redfish-check-cartridge-3.6 doesn't exist [ 71s] warning: %postun(python3-redfish-0.4.1-3.1.noarch) scriptlet failed, exit status 2

###

I created a subpackage python-redfish-common and required it in the preamble, as there are some files, that seem to exist or be needed in both the python2 and python3 package.

%files -n %{name}-common %config(noreplace) %{_sysconfdir}/redfish-client.conf %{_datadir}/redfish-client %{_mandir}/man1/python-redfish.1%{ext_man}

I have not tested, whether both versions can use the same config file (I guess so). There are some templates in %{_datadir}/redfish-client that seem to be needed by both versions.

Is this a valid approach? Or should I solve this differently? I found nothing (or missed it) in the singlespec page.

###

Thanks in advance for any hints, tips, tricks and comments!

Johannes