Hi, according to the "Fedora Packaging Guidelines for Python" [0] the "Example common spec file" [1] contained in those very same guidelines is wrong.
Specifically, the section "Naming" [2] in the guidelines says the following: (1) "Both python 2 and python 3 variants must provide symlinks with a '-X' and '-X.Y' suffix (python runtime major version, or python runtime major.minor version), unless upstream already provides appropriately versioned executables without the dash." (2) "The unversioned executable must be the python2 version." (3) "For example, the python3 version of "coverage" must ship executables /usr/bin/coverage-3 and /usr/bin/coverage-3.4 (assuming python3 is currently version 3.4), while the python2 version must provide /usr/bin/coverage, /usr/bin/coverage-2 and /usr/bin/coverage-2.7 (assuming python2 version 2.7)."
So given that, the "Example common spec file" [1] has the following problems: * The unversioned executable ('%{_bindir}/sample-exec') is provided by the python3- subpackage instead of the python2- subpackage. * In the %install section, the order of execution of the %py2_install and %py3_install macros is wrong, since it leads to python3- subpackage providing the unversioned executable. The comment in the section should be modified accordingly as well. * Neither python2- nor python3- subpackages provide symlinks to the '-X' suffix, i.e. 'sample-exec-2' and 'sample-exec-3'
[0] https://fedoraproject.org/wiki/Packagingython [1] https://fedoraproject.org/wiki/Packagingython#Example_common_spec_file [2] https://fedoraproject.org/wiki/Packagingython#Naming
Thank you for your time, Tomas Orsava
"TO" == Tomas Orsava torsava@redhat.com writes:
TO> Hi, according to the "Fedora Packaging Guidelines for Python" [0] TO> the "Example common spec file" [1] contained in those very same TO> guidelines is wrong.
I think you misunderstand.
TO> Specifically, the section "Naming" [2] in the guidelines says the TO> following:
But this section explicitly only covers the rare case where a py2 and py3 version of something provide _different_ functionality.
The example spec is for the normal case. That's why it's up above the "Avoiding collisions between the python 2 and python 3 stacks" section. That section covers a specific case which applies to only a few packages.
- J<
But this section explicitly only covers the rare case where a py2 and py3 version of something provide _different_ functionality.
The example spec is for the normal case. That's why it's up above the "Avoiding collisions between the python 2 and python 3 stacks" section. That section covers a specific case which applies to only a few packages.
Well, here's what the guidelines say about the normal case: "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only the Python 3 version of the executable should be packaged."
Since the spec file does package both p2 and p3 versions of the executable, I infer that we are indeed dealing with the case where it is beneficial to package both p2 and p3 version of the executable, in which case my first post applies and the example is wrong.
So in summary, either the example is wrong by packaging both p2 and p3 versions of the executable, or it is wrong by packaging the p3 version of the executable as the default one.
On Mon, Mar 21, 2016 at 06:46:00PM -0000, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so.
The example spec file does *not* package both versions of the executable.
Zbyszek
On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 21, 2016 at 06:46:00PM -0000, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so.
The example spec file does *not* package both versions of the executable.
Yes, it does.
%files -n python2-%{srcname} %license COPYING %doc README.rst %{python2_sitelib}/* %{_bindir}/sample-exec-2.7 <---- HERE
%files -n python3-%{srcname} %license COPYING %doc README.rst %{python3_sitelib}/* %{_bindir}/sample-exec <---- HERE %{_bindir}/sample-exec-3.4 <---- HERE
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok mhroncok@redhat.com wrote:
On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 21, 2016 at 06:46:00PM -0000, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so.
The example spec file does *not* package both versions of the executable.
Yes, it does.
%files -n python2-%{srcname} %license COPYING %doc README.rst %{python2_sitelib}/* %{_bindir}/sample-exec-2.7 <---- HERE
%files -n python3-%{srcname} %license COPYING %doc README.rst %{python3_sitelib}/* %{_bindir}/sample-exec <---- HERE %{_bindir}/sample-exec-3.4 <---- HERE
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
I would suggest that the unversioned binary shouldn't necessarily be part of a versioned python package (like pythonX-<module>), but I guess this is something that people expect these days anyway...
On Mon, Mar 21, 2016 at 05:35:03PM -0400, Neal Gompa wrote:
On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok mhroncok@redhat.com wrote:
On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 21, 2016 at 06:46:00PM -0000, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so.
The example spec file does *not* package both versions of the executable.
Yes, it does.
Ah, OK. It didn't at some point and I didn't check. It seems that the Guidelines:Python page could still use some editing. I think most of the info is there, but it's not very clear.
In particular, the multiple-executables case is again very prominent (as this thread shows), and it's really applicable to a miniscule percentage of packages (literally: sphinx, pytest, nosetest, a bunch of python development and installation tools. There's a spattering of other random packages, which might be mistakes. E.g. python-nibabel also provides versioned executables, but that I don't think there's a good reason for that). The way that Guidelines are written only serves to confuse packagers.
%files -n python2-%{srcname} %license COPYING %doc README.rst %{python2_sitelib}/* %{_bindir}/sample-exec-2.7 <---- HERE
%files -n python3-%{srcname} %license COPYING %doc README.rst %{python3_sitelib}/* %{_bindir}/sample-exec <---- HERE %{_bindir}/sample-exec-3.4 <---- HERE
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
I would suggest that the unversioned binary shouldn't necessarily be part of a versioned python package (like pythonX-<module>), but I guess this is something that people expect these days anyway...
The alternative would to add yet another subpackage. Most of the time that would be overkill. In the common case it works just fine to put the binaries in py2 or py3 subpackage.
Zbyszek
----- Original Message -----
From: "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl To: "Fedora Python SIG" python-devel@lists.fedoraproject.org Sent: Tuesday, March 22, 2016 2:54:44 AM Subject: Re: Inconsistencies in the Fedora Packaging Guidelines for Python
On Mon, Mar 21, 2016 at 05:35:03PM -0400, Neal Gompa wrote:
On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok mhroncok@redhat.com wrote:
On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 21, 2016 at 06:46:00PM -0000, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so.
The example spec file does *not* package both versions of the executable.
Yes, it does.
Ah, OK. It didn't at some point and I didn't check. It seems that the Guidelines:Python page could still use some editing. I think most of the info is there, but it's not very clear.
In particular, the multiple-executables case is again very prominent (as this thread shows), and it's really applicable to a miniscule percentage of packages (literally: sphinx, pytest, nosetest, a bunch of python development and installation tools. There's a spattering of other random packages, which might be mistakes. E.g. python-nibabel also provides versioned executables, but that I don't think there's a good reason for that). The way that Guidelines are written only serves to confuse packagers.
%files -n python2-%{srcname} %license COPYING %doc README.rst %{python2_sitelib}/* %{_bindir}/sample-exec-2.7 <---- HERE
%files -n python3-%{srcname} %license COPYING %doc README.rst %{python3_sitelib}/* %{_bindir}/sample-exec <---- HERE %{_bindir}/sample-exec-3.4 <---- HERE
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
I would suggest that the unversioned binary shouldn't necessarily be part of a versioned python package (like pythonX-<module>), but I guess this is something that people expect these days anyway...
The alternative would to add yet another subpackage. Most of the time that would be overkill. In the common case it works just fine to put the binaries in py2 or py3 subpackage.
I'll just leave this here
https://fedorahosted.org/fpc/ticket/558
Zbyszek _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject....
-- Robert Kuska {rkuska}
On Mon, Mar 21, 2016 at 05:35:03PM -0400, Neal Gompa wrote: Ah, OK. It didn't at some point and I didn't check. It seems that the Guidelines:Python page could still use some editing. I think most of the info is there, but it's not very clear.
In particular, the multiple-executables case is again very prominent (as this thread shows), and it's really applicable to a miniscule percentage of packages (literally: sphinx, pytest, nosetest, a bunch of python development and installation tools. There's a spattering of other random packages, which might be mistakes. E.g. python-nibabel also provides versioned executables, but that I don't think there's a good reason for that). The way that Guidelines are written only serves to confuse packagers.
So, I think we're in agreement that the example is not ideal and can be very confusing. As Robert pointed out, there's already a ticket for the change at: https://fedorahosted.org/fpc/ticket/558, however it appears to have been inactive for months. Would you know what can be done to get the example fixed?
Tomas
python-devel@lists.fedoraproject.org