#1 Update python-simpleparse.spec with new version including Python 3 subpackage
Closed 6 years ago by aries. Opened 6 years ago by aries.
rpms/ aries/python-simpleparse master  into  master

file modified
+28 -27
@@ -2,15 +2,13 @@ 

  

  Name:           python-simpleparse

  License:        BSD

- Group:          System Environment/Libraries

  Summary:        A simple and fast parser generator

- Version:        2.1.1

- Release:        17%{?dist}

+ Version:        2.2.0

+ Release:        1%{?dist}

  URL:            http://launchpad.net/simpleparse

- Source0:        http://pypi.python.org/packages/source/S/SimpleParse/%{oname}-%{version}.tar.gz

- Patch1:         %{name}-eols.patch

- BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

- BuildRequires:  python-devel

+ Source0:        https://pypi.io/packages/source/S/SimpleParse/%{oname}-%{version}.tar.gz

+ BuildRequires:  python2-devel

+ BuildRequires:  python3-devel

  

  %global _description\

  SimpleParse is a BSD-licensed Python package providing a simple and fast parser\
@@ -18,43 +16,46 @@ 

  SimpleParse allows you to generate parsers directly from your EBNF grammar.\

  \

  \

- # we don't want to provide mxTextTools.so\

- %{?filter_setup:\

- %filter_provides_in %{python_sitearch}/.*\.so$\

- %filter_setup\

- }

  

  %description %_description

  

  %package -n python2-simpleparse

- Summary: %summary

+ Summary:        %summary

  %{?python_provide:%python_provide python2-simpleparse}

  

  %description -n python2-simpleparse %_description

  

+ %package -n python3-simpleparse

+ Summary:        %summary

+ %{?python_provide:%python_provide python3-simpleparse}

+ 

+ %description -n python3-simpleparse %_description

+ 

  %prep

- %setup -q -n %{oname}-%{version}

- %patch1 -p0

+ %autosetup -n %{oname}-%{version}

  

  %build

- %{__python} setup.py build

+ %py2_build

+ %py3_build

  

  %install

- rm -rf %{buildroot}

- %{__python} setup.py install --skip-build --root %{buildroot}

- 

- 

- %clean

- rm -rf %{buildroot}

+ %py2_install

+ %py3_install

  

  %files -n python2-simpleparse

- %defattr(-,root,root,-)

- %{python_sitearch}

- %exclude %{python_sitearch}/simpleparse/tests

- %exclude %{python_sitearch}/simpleparse/examples

- %doc license.txt doc examples

+ %license license.txt

+ %doc doc

+ %{python2_sitearch}/*

+ 

+ %files -n python3-simpleparse

+ %license license.txt

+ %doc doc

+ %{python3_sitearch}/*

  

  %changelog

+ * Mon Oct 16 2017 Jan Beran <jberan@redhat.com> - 2.2.0-1

+ - New version including Python 3 subpackage

+ 

  * Sat Aug 19 2017 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> - 2.1.1-17

  - Python 2 binary package renamed to python2-simpleparse

    See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

Why we don't want to provide this? Is there a reason to remove it from the package?

I just follow the original intention to not provide mxTextTools.so (even it did not work). If you think that it does not make sense, I can remove the both exclusions. Then there will be a question, what to do with Python 3 *.so file that is named differently - some packagers prefer to keep the same name for the both Python 2 and Python 3 versions (mxTextTools.so in this case). What do you think, Miro?

I just follow the original intention to not provide mxTextTools.so (even it did not work).

I'm afraid you don't understand what was happening in the original spec file. The original intention was to filter out .so file from autogenrated provides, not from the package itself. Since then, those .so files in Python sitearch are no longer automatically provided and the filter is no longer needed. No .so files were ever removed from the package.

See https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

Then there will be a question, what to do with Python 3 *.so file that is named differently

Who shall ask this question? Python 2 and Python 3 name the .so files differently - that's the reason why they are named differently even in Fedora packages.

See for example standard library modules in /usr/lib64/python2.7/lib-dynload/ vs. /usr/lib64/python3.6/lib-dynload/.

some packagers prefer to keep the same name for the both Python 2 and Python 3 versions (mxTextTools.so in this case)

If such packagers exist, please point them to me. There is not reason to prefer to keep the name the same, other than "I like it so". If packages prefer to rename files just because they like it, I don't think it's a good practice.

1 new commit added

  • Correction of the updated python-simpleparse.spec
6 years ago

Will you close this PR if the new one is somehow better (they seem the same BTW)?

Pull-Request has been closed by aries

6 years ago
Metadata