Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1482977 - vertica-python: Provide a Python 3 subpackage
Summary: vertica-python: Provide a Python 3 subpackage
Alias: None
Product: Fedora
Classification: Fedora
Component: vertica-python
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: jakub.jedelsky
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-08-18 13:48 UTC by Iryna Shcherbina
Modified: 2018-12-02 00:11 UTC (History)
4 users (show)

Fixed In Version: python-vertica-0.7.4-1.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-02 00:11:16 UTC
Type: Bug

Attachments (Terms of Use)
New version including Python 3 subpackage (deleted)
2017-09-25 08:56 UTC, Jan Beran
no flags Details | Diff
Patch for older dateutil (deleted)
2017-09-25 08:57 UTC, Jan Beran
no flags Details | Diff
Updated spec file (deleted)
2017-10-13 13:21 UTC, jakub.jedelsky
no flags Details

Description Iryna Shcherbina 2017-08-18 13:48:03 UTC
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

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!


Comment 1 Jan Beran 2017-09-25 08:56:04 UTC
Created attachment 1330448 [details]
New version including Python 3 subpackage

Comment 2 Jan Beran 2017-09-25 08:57:21 UTC
Created attachment 1330449 [details]
Patch for older dateutil

Comment 3 Jan Beran 2017-09-25 08:59:45 UTC
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 14:23:36 UTC
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


Comment 5 Jan Beran 2017-10-11 08:19:43 UTC
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



Comment 6 Miro Hrončok 2017-10-12 13:53:21 UTC
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:


And that is usually abbreviated to python2-vertica, however, I cannot find a rule about that.

Comment 7 jakub.jedelsky 2017-10-13 13:21:32 UTC
Created attachment 1338229 [details]
Updated spec file

Comment 8 jakub.jedelsky 2017-10-13 13:22:35 UTC
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
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 16:20:28 UTC
The obsoleted version should be hardcoded, see

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 that describes how to do it.

Thank you.

Comment 10 Jan Beran 2017-10-14 09:51:46 UTC
Hi Jakub,

Patch0 should be replaced by the the newer version that I attached ( because the original source code had been modified.

Patch1 is not required any more because the source code has already been fixed (

Comment 11 Jan Beran 2018-01-08 13:24:02 UTC
Hi Jakub,

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

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

Please, could you review the changes, and if they are fine, add vertica-python-0.7.3-dateutil15.patch in Pagure files [], and rebuild the package?

Comment 12 Jan Beran 2018-01-08 18:30:11 UTC
I have created a new update at which includes Python build and install macros.

Comment 13 Fedora End Of Life 2018-02-20 15:34:01 UTC
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 07:56:21 UTC
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:

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.