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

Hi, On 10/13/2017 08:39 PM, Johannes Kastl 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. ;-) It is documented pretty good https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec If you think something is missing, please raise your voice :) 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

On 13.10.17 14:04 jan matejek wrote: 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. But there is no reason to use alternatives and it's complexity for users and packagers if there is no reason to do so. In other words: If both version versions are equivalent, only provide it once. This is the case for most user-facing programs written in python. Also: If the provided library is only useful for the executable, there is even no reason to provide both versions of it too. So it is probably not even necessary/recommended to singlespec' it at all. It depends on what the program actually does.

...

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... ;-( See also https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec#Subpackage_decl... and https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec#Requires.2C_Pro...

Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers