Bug 1482977 - vertica-python: Provide a Python 3 subpackage [NEEDINFO]
vertica-python: Provide a Python 3 subpackage
Status: NEW
Product: Fedora
Classification: Fedora
Component: vertica-python (Show other bugs)
28
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Jedelsky
Fedora Extras Quality Assurance
:
Depends On:
Blocks: PYTHON3 PY3PATCH-AVAILABLE
  Show dependency treegraph
 
Reported: 2017-08-18 09:48 EDT by Iryna Shcherbina
Modified: 2018-03-27 03:56 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jberan: needinfo? (jakub.jedelsky)
jberan: needinfo? (jakub.jedelsky)


Attachments (Terms of Use)
New version including Python 3 subpackage (4.73 KB, patch)
2017-09-25 04:56 EDT, Jan Beran
no flags Details | Diff
Patch for older dateutil (625 bytes, patch)
2017-09-25 04:57 EDT, Jan Beran
no flags Details | Diff
Updated spec file (4.90 KB, text/x-matlab)
2017-10-13 09:21 EDT, Jakub Jedelsky
no flags Details

  None (edit)
Description Iryna Shcherbina 2017-08-18 09:48:03 EDT
Upstream, this software supports Python 3. Please provide a Python 3
package for Fedora.


According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's OK to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 26 as well.


If you need more instructions, a guide for porting Python-based RPMs is
available at [2].
If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
[2] http://python-rpm-porting.readthedocs.io/
Comment 1 Jan Beran 2017-09-25 04:56 EDT
Created attachment 1330448 [details]
New version including Python 3 subpackage
Comment 2 Jan Beran 2017-09-25 04:57 EDT
Created attachment 1330449 [details]
Patch for older dateutil
Comment 3 Jan Beran 2017-09-25 04:59:45 EDT
Hello Jakub,

may I ask you to review the updated spec file, and if it is fine to rebuild?

Thank you.
Comment 4 Jakub Jedelsky 2017-10-10 10:23:36 EDT
Hi Honzo,

first, sorry for late answer.

Actually I'm not sure with naming. Your changes introduce name python{,2,3}-vertica. I would like to preserve current naming 'vertica-python' to be backwards compatible, though.

According to Naming guidelines [1] for python: "The package name should reflect the upstream name of the Python module", that's why I named it vertica-python (actually in time I prepared the first version of the package, guidelines said something like: 'package should be named with python- prefix, but if it includes python in its name, keep it there', if I remember correctly :)).

Is it ok to keep the name vertica-python{,2,3} for you? If so, I'll update spec file and push updates asap (I have a first attempt prepared locally).

Best regards,

- jj

[1] http://fedoraproject.org/wiki/Packaging:Naming#Python_modules
Comment 5 Jan Beran 2017-10-11 04:19:43 EDT
Hi Jakub,

I keep the whole package name without any change. So the backwards compatibility impact would be limited to the subpackages where I use python2-/python3- prefix because:

1. The naming guidelines [1] says also that "Python2 binary packages MUST be named using a python2- prefix" and "Python3 binary packages MUST be named with a prefix of python3-". Yes, it changed recently [2] and is addressed to new packages, but the policy is preferred for all binary packages [3].

2. There were already modified most of packages in Fedora with -python postfix that contain Python3 subpackage, in the same way. Just a few are pending. You can find them at [4] and look in their specfiles.

3. Some other Linux distributions prefer also the prefix format [5], [6].

Anyway, as I am not a package maintainer but you are, I think that you can decide which naming fashion is more convenient.

Best regards

Honza

[1] http://fedoraproject.org/wiki/Packaging:Naming#Python_modules
[2] https://fedoraproject.org/w/index.php?title=Packaging%3ANaming&diff=494430&oldid=479660
[3] https://pagure.io/packaging-committee/issue/685
[4] http://fedora.portingdb.xyz/#released
[5] https://packages.debian.org/sid/python3-vertica
[6] https://packages.ubuntu.com/search?keywords=python3-vertica
Comment 6 Miro Hrončok 2017-10-12 09:53:21 EDT
When a (sub)package is renamed from vertica-python, there MUST be provides and obsoletes added:

Provides: vertica-python == %{version}-%{release}
Obsoletes: vertica-python < HARDCODE THE VERSION RELEASE HERE

This will also hopefully satisfy Jakub's concerns about backwards compatibility.

As for the naming guidelines:

"The package name should reflect the upstream name of the Python module"

That would be vertica_python. So this package breaks the rule anyway ;)

So in fact, the proper name of the binary packages would be:

python2-vertica_python

And that is usually abbreviated to python2-vertica, however, I cannot find a rule about that.
Comment 7 Jakub Jedelsky 2017-10-13 09:21 EDT
Created attachment 1338229 [details]
Updated spec file
Comment 8 Jakub Jedelsky 2017-10-13 09:22:35 EDT
Honzo, Miro,

thanks for a lot of info there :) I prepared an update to the spec file, which should work as expected. Can you check, if it's ok, please?

Thanks a million!

There are some (more or less useful) outputs:

$ rpmlint vertica-python.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint results_vertica-python/0.7.3/1.fc27/vertica-python-0.7.3-1.fc28.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint results_vertica-python/0.7.3/1.fc27/python*-vertica-0.7.3-1.fc28.noarch.rpm
2 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpm -qRp results_vertica-python/0.7.3/1.fc27/python2-vertica-0.7.3-1.fc28.noarch.rpm
python(abi) = 2.7
python-dateutil >= 1.5
python-psycopg2
python2-future
pytz
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
$ rpm -qp --provides results_vertica-python/0.7.3/1.fc27/python2-vertica-0.7.3-1.fc28.noarch.rpm
python-vertica = 0.7.3-1.fc28
python2-vertica = 0.7.3-1.fc28
python2.7dist(vertica-python) = 0.7.3
python2dist(vertica-python) = 0.7.3
vertica-python = 0.7.3-1.fc28
$ rpm -qp --obsoletes results_vertica-python/0.7.3/1.fc27/python2-vertica-0.7.3-1.fc28.noarch.rpm
python-vertica < 0.7.3-1.fc28
vertica-python < 0.7.3-1.fc28
Comment 9 Miro Hrončok 2017-10-13 12:20:28 EDT
The obsoleted version should be hardcoded, see https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Other than that, it seems good now. 

Also, while reworking the spec, would you be so kind and use python2-foo (build)requires on Fedora? 

If you need to maintain EL compatibility, there is a Q&A section at https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Q.26A that describes how to do it.

Thank you.
Comment 10 Jan Beran 2017-10-14 05:51:46 EDT
Hi Jakub,

Patch0 should be replaced by the the newer version that I attached (https://bugzilla.redhat.com/attachment.cgi?id=1330449) because the original source code had been modified.

Patch1 is not required any more because the source code has already been fixed (https://github.com/uber/vertica-python/commit/4ba7fad4001dd494f8e0d63d0ac6d8dda3349dbb).
Comment 11 Jan Beran 2018-01-08 08:24:02 EST
Hi Jakub,

I have prepared Pagure PR that provides update to version 0.7.3 including Python 3 subpackage:

https://src.fedoraproject.org/rpms/vertica-python/pull-request/1

Note, I am not a packager and have limited access to Pagure, so I am not allowed to add vertica-python-0.7.3-dateutil15.patch in files from https://bugzilla.redhat.com/attachment.cgi?id=1330449.

Please, could you review the changes, and if they are fine, add vertica-python-0.7.3-dateutil15.patch in Pagure files [https://src.fedoraproject.org/rpms/vertica-python/tree/master], and rebuild the package?
Comment 12 Jan Beran 2018-01-08 13:30:11 EST
I have created a new update at https://src.fedoraproject.org/rpms/vertica-python/pull-request/2 which includes Python build and install macros.
Comment 13 Fedora End Of Life 2018-02-20 10:34:01 EST
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
Comment 14 Jan Beran 2018-03-27 03:56:21 EDT
Hi Jakub,

I have prepared an updated Pagure PR that provides version 0.7.3 including Python 3 subpackage and Python build and install macros:

https://src.fedoraproject.org/rpms/vertica-python/pull-request/4

Please, could you review the patch and rebuild the package?

Note You need to log in before you can comment on or make changes to this bug.