BuildRequires and Requires¶

Change BuildRequires from python-devel to python3-devel and adjust all other Requires and BuildRequires entries to point only to python3 packages.

It is very important that you don’t use any Python 2 dependencies as that would make your package depend both on Python version 2 and version 3, which would render your porting efforts useless.

%build¶

In the build section you can find a variety of macros, for example %py_build and its newer version %py2_build. You can freely substitute these by the new Python 3 macro %py3_build.

Occasionally you will find a custom build command prefixed by the %{__python} or %{__python2} macros, or in some cases just prefixed by the Python interpreter invoked without a macro at all, e.g.:

%{__python} setup.py build
    or
python setup.py build

In these cases first try substituting the whole build command by the new smart macro %py3_build which should in many cases correctly figure out what ought to be done automatically. Otherwise change the invocation of the Python interpreter to the %{__python3} macro.

In rare cases, you might encounter some non-Python build script such as a Makefile. In these instances you have to adjust the script on your own, consult the documentation for the specific build method.

%install and %check¶

The %install section will oftentimes contain the %py_install and %py2_install macros; you can replace these with the new Python 3 macro %py3_install.

Furthermore, as in the preceding %build section, you will frequently find custom scripts or commands prefixed by either the %{__python} or %{__python2} macros or simply preceded by an invocation of the Python interpreter without the use of macros at all.

In the install section, try substituting it with the new %py3_install macro, which should figure out what to do automatically. If that doesn’t work, or if you’re porting the %check section, just make sure that any custom scripts or commands are invoked by the new %{__python3} macro.

Again as in the %build section, in the rare cases where you encounter a non-Python install script such as a Makefile, consult documentation for the specific install method and make adjustments on your own.

Lastly, in the %check section you can also encounter a custom Python command that runs the tests, such as nosetests or py.test. In that case find out what is the name of the executable for Python 3 and use it instead of the Python 2 version.

%check
py.test-3
or
nosetests-%{python3_version}

As you can see on the example of the nosetests, not all packages follow the proper naming conventions for executables. To list what executables a package contains, you can use:

$ dnf repoquery -l python3-nose | grep /usr/bin/
/usr/bin/nosetests-3.4

%files¶

In the files section you can regularly find the following macros: %{python2_sitelib}, %{python2_sitearch}, %{python2_version}, %{python2_version_nodots} or their unversioned alternatives. Substitute these with their counterparts for Python 3, e.g. %{python3_sitelib}.

The files section may also contain the versioned executable, usually %{_bindir}/sample-exec-2.7 in which case it should be substituted by %{_bindir}/sample-exec-%{python3_version}.

Are shebangs dragging you down (to Python 2)?¶

A shebang is an indicator on the first line of an executable script that indicates in what interpreter is the script supposed to be launched, examples include python, bash and perl. When software gets ported to Python 3, the lone shebang often remains forgotten and keeps pointing to Python 2. In most cases this is handled automatically: the setup.py script (usually run through the %py3_build and %py3_install RPM macros) adjusts shebangs for you. However, sometimes it’s up to you to handle the situation.

RPM has very good capabilities of automatically finding dependencies, and one of the ways it accomplishes that is by looking at the shebangs of all the files in the package. Therefore it is important to check if the shebangs are not dragging in a runtime dependency on Python 2.

As the porting of the spec file is nearly finished, build it and then run the following analysis on the resulting Python 3 RPM file:

$ rpm -qp --requires path/to/an.rpm | grep -E '/usr/bin/(python|env)'

This will list all the Python executables your RPM package depends on as well as the /usr/bin/env executable which usually invokes python. The use of env is dangerous: applications should be using the safe system version of Python and not trust whatever version env might try to substitute. If you find that an RPM package for Python 3 depends on Python 2 or /usr/bin/env you need to fix it.

$ # Searches for all shebangs among the sources
$ grep -r '^#!/' .

$ # Searches only Python shebangs
$ grep -rE '^#!/usr/bin/(python|env python)' .

#!/usr/bin/python
#!/usr/bin/env python

$ # Change shebang in individual files
$ sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' path/to/file1 file2 file3 ...

$ # Change shebang in all relevant files in this directory and all subdirectories
$ # See `man find` for how the `-exec command ;` syntax works
$ find . -type f -exec sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' {} \;

$ # Change shebang in all relevant executable files in this directory and all subdirectories
$ find . -type f -executable -exec sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' {} \;

Creating subpackages¶

Each subpackage you create will need to have its own name, summary and description. If you haven’t already, it is thus advised to declare macros for common values at the top of the specfile:

%global srcname example
%global sum An example Python tool

Now we can use these to create the subpackages. The following should be placed beneath the %description section of the base package:

%package -n python2-%{srcname}
Summary:  %{sum}
Requires: python-some-module
Requires: python2-other-module
%{?python_provide:%python_provide python2-%{srcname}}

%description -n python2-%{srcname}
A Python tool which provides a convenient example.


%package -n python3-%{srcname}
Summary:  %{sum}
Requires: python3-some-module
Requires: python3-other-module
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

First, using the %package macro you start defining a new subpackage, specifying its full name as python2-%{srcname}, which in this case will become python2-example. Next we provide the summary through the macro we defined earlier.

BuildRequires: tags from the original spec file will remain where they are—declared in the definition of the base package at the top of the spec file. However, the runtime requirements—the ones listed using the Requires: tag—will be different for the two subpackages, so they have to be moved here to the definition of each subpackage.

While you can cut and paste all the Requires: tags directly from the base package to the python2- subpackage, remember that for the python3- subpackage you need to find Python 3 versions of each of the runtime dependencies.

%{?python_provide:%python_provide python2-%{srcname}}
and
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

BuildRequires and Requires¶

Now that you’re building subpackages for both Python 2 and Python 3, you need to adjust the BuildRequires: by adding Python 3 versions of all the existing build dependencies. Starting with python-devel: Use its new version-specific name python2-devel and add it’s Python 3 equivalent python3-devel.

As described above, Requires: tags are a bit more complicated. You should move the current set of Requires: underneath the definition of the Python 2 subpackage, and for the Python 3 subpackage, you need to find Python 3 alternatives for all the current Python 2 runtime requirements that are specified with the Requires: tags.

%build¶

Currently your package is building the software for Python 2, what we need to do is also add building for Python 3. While we’re modifying the spec file, however, it’s a good idea to also update it to new standards—in this case a new macro.

In the ideal case, you’ll find the build done with either the %py2_build macro or its older version %py_build, which you then should exchange for the former. In either case, you can just add the macro %py3_build afterwards, and this part is done.

%build
%py2_build
%py3_build

In many cases, however, you will find a custom build command prefixed by the %{__python} or %{__python2} macros, or in some cases just prefixed by the python interpreter invoked without a macro at all, e.g.:

%{__python} custombuild.py --many-flags
    or
python custombuild.py --many-flags

In these cases first try substituting the whole build command by the new pair of smart macros %py2_build and %py3_build, which should in many cases correctly figure out what ought to be done automatically. Otherwise, duplicate the entire command and change the invocation of the python interpreter to the %{__python2} macro in one of them and to the %{__python3} in the other.

%build
%{__python2} custombuild.py --many-flags
%{__python3} custombuild.py --many-flags

Rarely, you might encounter some non-Python build script such as a Makefile. In these instances you have to adjust the script on your own, consult the documentation for the specific build method.

%install¶

First, in the same manner as in the preceding %build section, it is advisable to upgrade the current Python 2 install command to use the new %py2_install macro, however, if that doesn’t work for you, you can stick with the current install command, just make sure it’s invoked by the %{__python2} macro.

After that, add the corresponding Python 3 install command, which will be either the custom command prefixed by %{__python3} or the new %py3_install macro.

%install
%py2_install
%py3_install

Again as in the %build section, in the rare cases where you encounter a non-Python install script such as a Makefile, consult documentation for the specific install method and make adjustments on your own.

%check¶

Unlike in previous sections, there’s no special macro for the %check section, and so here if the original spec file uses any sort of a python script for testing, just make sure that the tests are invoked once using the %{__python2} macro and a second time using the %{__python3} macro.

%check
%{__python2} setup.py test
%{__python3} setup.py test

Chances are that you will encounter a custom Python command that runs the tests, such as nosetests or py.test. In that case find out what is the name of the executable for Python 3 and run it after the Python 2 command.

If the command for Python 2 can be invoked explicitly for Python 2, e.g. as py.test-2 instead of just py.test, use it.

%check
py.test-2
py.test-3

or

nosetests-%{python2_version}
nosetests-%{python3_version}

As you can see on the example of the nosetests, not all packages follow the proper naming conventions for executables. To list what executables a package contains, you can use:

$ dnf repoquery -l python3-nose | grep /usr/bin/
/usr/bin/nosetests-3.4

%files¶

The presence or absence of a %files section is the deciding factor in whether a given package or subpackage gets built or not. Therefore, to assure that our base package doesn’t get built (as all the content has been moved to the two subpackages), make sure there is no %files section without a subpackage name.

You can reuse the current %files section for the Python 2 submodule by giving it the appropriate package name. You can keep it almost the same as before, just make sure that, where appropriate, it uses the new macros %{python2_sitelib}, %{python2_sitearch}, %{python2_version} or perhaps %{python2_version_nodots}.

%files -n python2-%{srcname}
%license COPYING
%doc README
%{python2_sitelib}/*

Accordingly we’ll also add a %files section for the Python 3 subpackage. You can copy the previous files section, but make sure you change all the Python 2 macros into Python 3 versions.

%files -n python3-%{srcname}
%license COPYING
%doc README
%{python3_sitelib}/*

Creating subpackages¶

Each subpackage you create will need to have its own name, summary and description. If you haven’t already, it is thus advised to declare macros for common values at the top of the specfile:

%global srcname example
%global sum An example Python tool

Now we can use these to create the subpackages. The following should be placed beneath the %description section of the base package:

%package -n python2-%{srcname}
Summary:  %{sum}
Requires: python-some-module
Requires: python2-other-module
%{?python_provide:%python_provide python2-%{srcname}}

%description -n python2-%{srcname}
A Python tool which provides a convenient example.


%package -n python3-%{srcname}
Summary:  %{sum}
Requires: python3-some-module
Requires: python3-other-module
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

First, using the %package macro you start defining a new subpackage, specifying its full name as python2-%{srcname}, which in this case will become python2-example. Next we provide the summary through the macro we defined earlier.

BuildRequires: tags from the original spec file will remain where they are—declared in the definition of the base package at the top of the spec file. However, the runtime requirements—the ones listed using the Requires: tag—will be different for the two subpackages, so they have to be moved here to the definition of each subpackage.

While you can cut and paste all the Requires: tags directly from the base package to the python2- subpackage, remember that for the python3- subpackage you need to find Python 3 versions of each of the runtime dependencies.

%{?python_provide:%python_provide python2-%{srcname}}
and
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

BuildRequires and Requires¶

Now that you’re building subpackages for both Python 2 and Python 3, you need to adjust the BuildRequires: by adding Python 3 versions of all the existing build dependencies. Starting with python-devel: Use its new version-specific name python2-devel and add it’s Python 3 equivalent python3-devel.

As described above, Requires: tags are a bit more complicated. You should move the current set of Requires: underneath the definition of the Python 2 subpackage, and for the Python 3 subpackage, you need to find Python 3 alternatives for all the current Python 2 runtime requirements that are specified with the Requires: tags.

As we will be including the executable (application) only in the Python 3 subpackage, you may be also able to get rid of some runtime dependencies (listed using the Requires: tags) in the Python 2 subpackage that were previously used only by the executable and are therefore no longer needed in that subpackage. However, figuring out what runtime dependencies are no longer needed is a problematic task, therefore if you are unsure of which dependencies can be omitted, you can skip this task.

%build¶

Currently your package is building the software for Python 2, what we need to do is also add building for Python 3. While we’re modifying the spec file, however, it’s a good idea to also update it to new standards—in this case a new macro.

In the ideal case, you’ll find the build done with either the %py2_build macro or its older version %py_build, which you then should exchange for the former. In either case, you can just add the macro %py3_build afterwards, and this part is done.

%build
%py2_build
%py3_build

In many cases, however, you will find a custom build command prefixed by the %{__python} or %{__python2} macros, or in some cases just prefixed by the python interpreter invoked without a macro at all, e.g.:

%{__python} custombuild.py --many-flags
    or
python custombuild.py --many-flags

In these cases first try substituting the whole build command by the new pair of smart macros %py2_build and %py3_build, which should in many cases correctly figure out what ought to be done automatically. Otherwise, duplicate the entire command and change the invocation of the python interpreter to the %{__python2} macro in one of them and to the %{__python3} in the other.

%build
%{__python2} custombuild.py --many-flags
%{__python3} custombuild.py --many-flags

Rarely, you might encounter some non-Python build script such as a Makefile. In these instances you have to adjust the script on your own, consult the documentation for the specific build method.

%install¶

First, in the same manner as in the preceding %build section, it is advisable to upgrade the current Python 2 install command to use the new %py2_install macro, however, if that doesn’t work for you, you can stick with the current install command, just make sure it’s invoked by the %{__python2} macro.

After the Python 2 install macro is run, it is likely going to install the Python 2 version of the application. As we want to package only the Python 3 version of the application, we have to remove the Python 2 executable(s) that were installed into /usr/bin/ so that the Python 3 version(s) can take their place afterwards.

%install
%py2_install
rm %{buildroot}%{_bindir}/*

After that, add the corresponding Python 3 install command, which will be either the custom command prefixed by %{__python3} or the new %py3_install macro.

%py3_install

Again as in the %build section, in the rare cases where you encounter a non-Python install script such as a Makefile, consult documentation for the specific install method and make adjustments on your own.

%check¶

Unlike in previous sections, there’s no special macro for the %check section, and so here if the original spec file uses any sort of a python script for testing, just make sure that the tests are invoked once using the %{__python2} macro and a second time using the %{__python3} macro.

%check
%{__python2} setup.py test
%{__python3} setup.py test

Chances are that you will encounter a custom Python command that runs the tests, such as nosetests or py.test. In that case find out what is the name of the executable for Python 3 and run it after the Python 2 command.

If the command for Python 2 can be invoked explicitly for Python 2, e.g. as py.test-2 instead of just py.test, use it.

%check
py.test-2
py.test-3

or

nosetests-%{python2_version}
nosetests-%{python3_version}

As you can see on the example of the nosetests, not all packages follow the proper naming conventions for executables. To list what executables a package contains, you can use:

$ dnf repoquery -l python3-nose | grep /usr/bin/
/usr/bin/nosetests-3.4

%files¶

The presence or absence of a %files section is the deciding factor in whether a given package or subpackage gets built or not. Therefore, to assure that our base package doesn’t get built (as all the content has been moved to the two subpackages), make sure there is no %files section without a subpackage name.

You can reuse the current %files section for the Python 2 submodule by giving it the appropriate package name. You can keep it almost the same as before, just make sure that, where appropriate, it uses the new macros %{python2_sitelib}, %{python2_sitearch}, %{python2_version} or perhaps %{python2_version_nodots}.

However, be sure not to include the executable. The Fedora Packaging Guidelines for Python state that if you are packaging only one executable, it should be the one for Python 3.

%files -n python2-%{srcname}
%license COPYING
%doc README
%{python2_sitelib}/*

We’ll also add a %files section for the Python 3 subpackage. You can copy the previous files section, but make sure you change all the Python 2 macros into Python 3 versions. And in this case, do not forget to include the executable as well.

%files -n python3-%{srcname}
%license COPYING
%doc README
%{python3_sitelib}/*
%{_bindir}/sample-exec

Are shebangs dragging you down (to Python 2)?¶

A shebang is an indicator on the first line of an executable script that indicates in what interpreter is the script supposed to be launched, examples include python, bash and perl. When software gets ported to Python 3, the lone shebang often remains forgotten and keeps pointing to Python 2. In most cases this is handled automatically: the setup.py script (usually run through the %py3_build and %py3_install RPM macros) adjusts shebangs for you. However, sometimes it’s up to you to handle the situation.

RPM has very good capabilities of automatically finding dependencies, and one of the ways it accomplishes that is by looking at the shebangs of all the files in the package. Therefore it is important to check if the shebangs are not dragging in a runtime dependency on Python 2.

As the porting of the spec file is nearly finished, build it and then run the following analysis on the resulting Python 3 RPM file:

$ rpm -qp --requires path/to/an.rpm | grep -E '/usr/bin/(python|env)'

This will list all the Python executables your RPM package depends on as well as the /usr/bin/env executable which usually invokes python. The use of env is dangerous: applications should be using the safe system version of Python and not trust whatever version env might try to substitute. If you find that an RPM package for Python 3 depends on Python 2 or /usr/bin/env you need to fix it.

$ # Searches for all shebangs among the sources
$ grep -r '^#!/' .

$ # Searches only Python shebangs
$ grep -rE '^#!/usr/bin/(python|env python)' .

#!/usr/bin/python
#!/usr/bin/env python

$ # Change shebang in individual files
$ sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' path/to/file1 file2 file3 ...

$ # Change shebang in all relevant files in this directory and all subdirectories
$ # See `man find` for how the `-exec command ;` syntax works
$ find . -type f -exec sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' {} \;

$ # Change shebang in all relevant executable files in this directory and all subdirectories
$ find . -type f -executable -exec sed -i '1s_^#!/usr/bin/\(python\|env python\)_#!%{__python3}_' {} \;

Creating subpackages¶

Each subpackage you create will need to have its own name, summary and description. If you haven’t already, it is thus advised to declare macros for common values at the top of the specfile:

%global srcname example
%global sum An example Python tool

Now we can use these to create the subpackages. The following should be placed beneath the %description section of the base package:

%package -n python2-%{srcname}
Summary:  %{sum}
Requires: python-some-module
Requires: python2-other-module
%{?python_provide:%python_provide python2-%{srcname}}

%description -n python2-%{srcname}
A Python tool which provides a convenient example.


%package -n python3-%{srcname}
Summary:  %{sum}
Requires: python3-some-module
Requires: python3-other-module
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

First, using the %package macro you start defining a new subpackage, specifying its full name as python2-%{srcname}, which in this case will become python2-example. Next we provide the summary through the macro we defined earlier.

BuildRequires: tags from the original spec file will remain where they are—declared in the definition of the base package at the top of the spec file. However, the runtime requirements—the ones listed using the Requires: tag—will be different for the two subpackages, so they have to be moved here to the definition of each subpackage.

While you can cut and paste all the Requires: tags directly from the base package to the python2- subpackage, remember that for the python3- subpackage you need to find Python 3 versions of each of the runtime dependencies.

%{?python_provide:%python_provide python2-%{srcname}}
and
%{?python_provide:%python_provide python3-%{srcname}}

%description -n python3-%{srcname}
A Python tool which provides a convenient example.

BuildRequires and Requires¶

Now that you’re building subpackages for both Python 2 and Python 3, you need to adjust the BuildRequires: by adding Python 3 versions of all the existing build dependencies. Starting with python-devel: Use its new version-specific name python2-devel and add it’s Python 3 equivalent python3-devel.

As described above, Requires: tags are a bit more complicated. You should move the current set of Requires: underneath the definition of the Python 2 subpackage, and for the Python 3 subpackage, you need to find Python 3 alternatives for all the current Python 2 runtime requirements that are specified with the Requires: tags.

%build¶

Currently your package is building the software for Python 2, what we need to do is also add building for Python 3. While we’re modifying the spec file, however, it’s a good idea to also update it to new standards—in this case a new macro.

In the ideal case, you’ll find the build done with either the %py2_build macro or its older version %py_build, which you then should exchange for the former. In either case, you can just add the macro %py3_build afterwards, and this part is done.

%build
%py2_build
%py3_build

In many cases, however, you will find a custom build command prefixed by the %{__python} or %{__python2} macros, or in some cases just prefixed by the python interpreter invoked without a macro at all, e.g.:

%{__python} custombuild.py --many-flags
    or
python custombuild.py --many-flags

In these cases first try substituting the whole build command by the new pair of smart macros %py2_build and %py3_build, which should in many cases correctly figure out what ought to be done automatically. Otherwise, duplicate the entire command and change the invocation of the python interpreter to the %{__python2} macro in one of them and to the %{__python3} in the other.

%build
%{__python2} custombuild.py --many-flags
%{__python3} custombuild.py --many-flags

Rarely, you might encounter some non-Python build script such as a Makefile. In these instances you have to adjust the script on your own, consult the documentation for the specific build method.

%install¶

The %install section is perhaps the most crucial one, because we have to be very mindful of which executable goes where and what symlinks should be created.

First, in the same manner as in the preceding %build section, it is advisable to upgrade the current Python 2 install command to use the new %py2_install macro, however, if that doesn’t work for you, you can stick with the current install command, just make sure it’s invoked by the %{__python2} macro. The corresponding Python 3 install command will then either be the custom command prefixed by %{__python3} or the new %py3_install macro, which I’ll be using in this example.

Again as in the %build section, in the rare cases where you encounter a non-Python install script such as a Makefile, consult documentation for the specific install method and make adjustments on your own.

As the packaging guidelines specify, the Python 2 package is currently to be the default one, thus it is best if we first install the Python 3 version of our software and then the one for Python 2, because in case they are installing some files into the same directories (such as /usr/bin/), one installation will overwrite the files of the other. So if we install the Python 2 version last, its files will be located in those shared directories.

%install
%py3_install

# Now /usr/bin/sample-exec is Python 3, so we move it away
mv %{buildroot}%{_bindir}/sample-exec %{buildroot}%{_bindir}/sample-exec-%{python3_version}

%py2_install

# Now /usr/bin/sample-exec is Python 2, and we move it away anyway
mv %{buildroot}%{_bindir}/sample-exec %{buildroot}%{_bindir}/sample-exec-%{python2_version}

# The guidelines also specify we must provide symlinks with a '-X' suffix.
ln -s ./sample-exec-%{python2_version} %{buildroot}%{_bindir}/sample-exec-2
ln -s ./sample-exec-%{python3_version} %{buildroot}%{_bindir}/sample-exec-3

# Finally, we provide /usr/bin/sample-exec as a link to /usr/bin/sample-exec-2
ln -s ./sample-exec-2 %{buildroot}%{_bindir}/sample-exec

%check¶

Unlike in previous sections, there’s no special macro for the %check section, and so here if the original spec file uses any sort of a python script for testing, just make sure that the tests are invoked once using the %{__python2} macro and a second time using the %{__python3} macro.

%check
%{__python2} setup.py test
%{__python3} setup.py test

Chances are that you will encounter a custom Python command that runs the tests, such as nosetests or py.test. In that case find out what is the name of the executable for Python 3 and run it after the Python 2 command.

If the command for Python 2 can be invoked explicitly for Python 2, e.g. as py.test-2 instead of just py.test, use it.

%check
py.test-2
py.test-3

or

nosetests-%{python2_version}
nosetests-%{python3_version}

As you can see on the example of the nosetests, not all packages follow the proper naming conventions for executables. To list what executables a package contains, you can use:

$ dnf repoquery -l python3-nose | grep /usr/bin/
/usr/bin/nosetests-3.4

%files¶

The presence or absence of a %files section is the deciding factor in whether a given package or subpackage gets built or not. Therefore, to assure that our base package doesn’t get built (as all the content has been moved to the two subpackages), make sure there is no %files section without a subpackage name.

You can reuse the current %files section for the Python 2 submodule by giving it the appropriate package name. You can keep it almost the same as before, just make sure that, where appropriate, it uses the new macros %{python2_sitelib}, %{python2_sitearch}, %{python2_version} or perhaps %{python2_version_nodots}. Finally, don’t forget to add the two new locations of the executable we’ve made available through the symlinks.

%files -n python2-%{srcname}
%license COPYING
%doc README
%{python2_sitelib}/*
%{_bindir}/sample-exec
%{_bindir}/sample-exec-2
%{_bindir}/sample-exec-%{python2_version}

Accordingly we’ll also add a %files section for the Python 3 subpackage. You can copy the previous files section, but make sure you change all the Python 2 macros into Python 3 versions. And unlike the former, the Python 3 %files section shall not contain the unversioned executable (sample-exec in our example) as that executable is for Python 2, not 3.

%files -n python3-%{srcname}
%license COPYING
%doc README
%{python3_sitelib}/*
%{_bindir}/sample-exec-3
%{_bindir}/sample-exec-%{python3_version}