| |
@@ -50,13 +50,13 @@
|
| |
Source0: %pypi_source
|
| |
|
| |
BuildArch: noarch
|
| |
- BuildRequires: python2-devel python3-devel
|
| |
|
| |
%description
|
| |
An python module which provides a convenient example.
|
| |
|
| |
%package -n python2-%{srcname}
|
| |
Summary: %{summary}
|
| |
+ BuildRequires: python2-devel
|
| |
%{?python_provide:%python_provide python2-%{srcname}}
|
| |
|
| |
%description -n python2-%{srcname}
|
| |
@@ -65,6 +65,7 @@
|
| |
|
| |
%package -n python3-%{srcname}
|
| |
Summary: %{summary}
|
| |
+ BuildRequires: python3-devel
|
| |
%{?python_provide:%python_provide python3-%{srcname}}
|
| |
|
| |
%description -n python3-%{srcname}
|
| |
@@ -174,6 +175,108 @@
|
| |
|
| |
You'll notice that the `+%build+`, `+%install+`, and `+%check+` sections again follow a pattern similar to the previous example. They switch to the python2 directory and do the normal steps for building the python2 module, and then switch to the python3 directory and run the same steps for python3. The usage of `+pushd/popd+` commands will ensure that the directories are logged.
|
| |
|
| |
+ === Conditionalizing the Python 2 parts
|
| |
+
|
| |
+ If the maintainer wishes to support a similar specfile across several Fedora releases,
|
| |
+ sometimes the Python 2 packages are only appropriate for the older ones.
|
| |
+ Conditionalizing the Python 2 parts of the specfile (if applicable)
|
| |
+ SHOULD be done with the following bcond:
|
| |
+
|
| |
+ ....
|
| |
+ %bcond_with python2 # to disable python2 by default, or:
|
| |
+ %bcond_without python2 # to enable python2 by default
|
| |
+
|
| |
+ %if %{with python2}
|
| |
+ ...
|
| |
+ %endif
|
| |
+ ....
|
| |
+
|
| |
+ See the following example for reference:
|
| |
+
|
| |
+ ....
|
| |
+ %global srcname example
|
| |
+
|
| |
+ # Disable python2 by default
|
| |
+ %bcond_with python2
|
| |
+
|
| |
+ Name: python-%{srcname}
|
| |
+ Version: 1.2.3
|
| |
+ Release: 1%{?dist}
|
| |
+ Summary: An example python module
|
| |
+
|
| |
+ License: MIT
|
| |
+ URL: https://pypi.python.org/pypi/%{srcname}
|
| |
+ Source0: %pypi_source
|
| |
+
|
| |
+ BuildArch: noarch
|
| |
+
|
| |
+
|
| |
+ %description
|
| |
+ An python module which provides a convenient example.
|
| |
+
|
| |
+
|
| |
+ %if %{with python2}
|
| |
+ %package -n python2-%{srcname}
|
| |
+ Summary: %{summary}
|
| |
+ BuildRequires: python2-devel
|
| |
+ %{?python_provide:%python_provide python2-%{srcname}}
|
| |
+
|
| |
+ %description -n python2-%{srcname}
|
| |
+ An python module which provides a convenient example.
|
| |
+ %endif
|
| |
+
|
| |
+
|
| |
+ %package -n python3-%{srcname}
|
| |
+ Summary: %{summary}
|
| |
+ BuildRequires: python3-devel
|
| |
+ %{?python_provide:%python_provide python3-%{srcname}}
|
| |
+
|
| |
+ %description -n python3-%{srcname}
|
| |
+ An python module which provides a convenient example.
|
| |
+
|
| |
+
|
| |
+ %prep
|
| |
+ %autosetup -n %{srcname}-%{version}
|
| |
+
|
| |
+ %build
|
| |
+ %if %{with python2}
|
| |
+ %py2_build
|
| |
+ %endif
|
| |
+ %py3_build
|
| |
+
|
| |
+ %install
|
| |
+ # Must do the python2 install first because the scripts in /usr/bin are
|
| |
+ # overwritten with every setup.py install, and in general we want the
|
| |
+ # python3 version to be the default.
|
| |
+ %if %{with python2}
|
| |
+ %py2_install
|
| |
+ %endif
|
| |
+ %py3_install
|
| |
+
|
| |
+ %check
|
| |
+ %if %{with python2}
|
| |
+ %{__python2} setup.py test
|
| |
+ %endif
|
| |
+ %{__python3} setup.py test
|
| |
+
|
| |
+ %if %{with python2}
|
| |
+ %files -n python2-%{srcname}
|
| |
+ %license COPYING
|
| |
+ %doc README.rst
|
| |
+ %{python2_sitelib}/%{srcname}/
|
| |
+ %{python2_sitelib}/%{srcname}-*.egg-info/
|
| |
+ %endif
|
| |
+
|
| |
+ %files -n python3-%{srcname}
|
| |
+ %license COPYING
|
| |
+ %doc README.rst
|
| |
+ %{python3_sitelib}/%{srcname}/
|
| |
+ %{python3_sitelib}/%{srcname}-*.egg-info/
|
| |
+ %{_bindir}/sample-exec
|
| |
+
|
| |
+ %changelog
|
| |
+ ....
|
| |
+
|
| |
=== Avoiding collisions between the python 2 and python 3 stacks
|
| |
|
| |
The python 2 and python 3 stacks are intended to be fully-installable in parallel. When generalizing the package for both python 2 and python 3, it is important to ensure that two different built packages do not attempt to place different payloads into the same path.
|
| |
churchyard
commented 5 years ago
Voted in: https://pagure.io/packaging-committee/issue/876#comment-565769