python-redfish singlespec conversion: update-alternatives, subpackage common

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

python-redfish singlespec conversion: update-alternatives, subpackage common

Johannes Kastl-2
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


signature.asc (900 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python-redfish singlespec conversion: update-alternatives, subpackage common

jan matejek-4
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
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python-redfish singlespec conversion: update-alternatives, subpackage common

Johannes Kastl-2
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


signature.asc (900 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python-redfish singlespec conversion: update-alternatives, subpackage common

Sebastian-2
Hi,

On 10/13/2017 08:39 PM, Johannes Kastl wrote:

> 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. ;-)
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
> 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_declarations
and
https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec#Requires.2C_Provides_and_similar

Sebastian

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



signature.asc (871 bytes) Download Attachment