Bug 1634549 - python-designateclient: Remove (sub)packages from Fedora 30+: python2-designateclient, python2-designateclient-tests
Summary: python-designateclient: Remove (sub)packages from Fedora 30+: python2-designa...
Alias: None
Product: Fedora
Classification: Fedora
Component: python-designateclient
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Victoria Martinez de la Cruz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-10-01 08:50 UTC by Miro Hrončok
Modified: 2019-03-08 10:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-03-08 10:31:17 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
RDO 17023 0 None None None 2018-10-23 15:59:53 UTC
RDO 17220 0 None None None 2018-11-02 15:52:17 UTC

Description Miro Hrončok 2018-10-01 08:50:51 UTC
In line with the Mass Python 2 Package Removal [0], the following (sub)packages of python-designateclient were marked for removal:

 * python2-designateclient-tests

According to our query, those (sub)packages only provide a Python 2 importable module. If this is not true, please tell us why, so we can fix our query.

Please remove them from your package.

As said in the change document, if there is no objection in a week, we will remove the package(s) as soon as we get to it. This change might not match your packaging style, so we'd prefer if you did the change. If you need more time, please let us know here.

We hope this doesn't come to you as a surprise. If you want to know our motivation for this, please read the change document [0].

[0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

Comment 1 Miro Hrončok 2018-10-18 16:42:19 UTC
python2-designateclient is only required by python2-designateclient-tests.

Please remove them both and move /usr/bin/designate to python3-designateclient.

Comment 2 Miro Hrončok 2018-10-23 17:05:12 UTC
I don't probably have and RDO Gerrit account so I'll comment here:

%global pyver_bin python%{pyver}
%global pyver_sitelib %python%{pyver}_sitelib
%global pyver_install %py%{pyver}_install
%global pyver_build %py%{pyver}_build

This is totally redundant. If you set %__python to %__python3 or %__python2, all of the following works properly:


$ rpm --define '__python %__python3'  --eval '%python_version'

Comment 3 Miro Hrončok 2018-10-23 17:08:21 UTC
See for example https://src.fedoraproject.org/rpms/python-ryu/pull-request/13#request_diff

Comment 4 Victoria Martinez de la Cruz 2018-10-25 17:48:10 UTC
It's not redundant, we are covering for different OS versions. With the proposed fix we are getting py2 packages for those distros that still have py2 (CentOS7) and py3 for those distros that have py3 (Fedora 28)

Comment 5 Miro Hrončok 2018-10-25 19:16:23 UTC
I've never said your fix is redundant. The macros you define are redundant.

You are defining your own "universal" macros, but the "universal" macros already exist.

If you set %__python to a specific value, all of the macros get redefined.

i.e. instead of:

%global pyver 3
%global pyver_bin python%{pyver}
%global pyver_sitelib %python%{pyver}_sitelib
%global pyver_install %py%{pyver}_install
%global pyver_build %py%{pyver}_build

You do:

%global __python %__python3

And you can use:


For Python 3.

Or you do:

%global __python %__python2

To use them for Python 2.

Comment 6 Victoria Martinez de la Cruz 2018-11-02 15:52:17 UTC
Got it, submitted a follow up patch. Thanks!

Comment 7 Miro Hrončok 2018-11-02 16:19:35 UTC

Comment 8 Victoria Martinez de la Cruz 2018-11-05 15:21:18 UTC
Tried this approach, it's not working as expected. %{python_sitelib} translates to python2 in python3 environments and the build fails. We need the macros. Dropping the patch and marking this as MODIFIED.

Comment 9 Miro Hrončok 2018-11-05 18:35:58 UTC
> %{python_sitelib} translates to python2 in python3 environments

What is a python3 environment?

Can you give me a reproducer, because that would be a bug.

I cannot reproduce it on Fedora:

$ rpm --define '__python %__python3'  --eval '%python_sitelib'

Comment 10 Victoria Martinez de la Cruz 2018-11-05 19:22:29 UTC
Check out logs in the Fedora gate https://review.rdoproject.org/r/#/c/17220/.

I've discussed this with other RDO packagers and the macros are needed.

Plus, create a user for review.rdoproject.org. It's easier to review patches that way.


Comment 11 Miro Hrončok 2018-11-05 19:51:59 UTC
I cannot reproduce your build failure on Fedora 30. Sorry.
Maybe it's a Fedora 28 bug, I'll cahck that later.

However, feel free to keep the macros as they are or investigate (I only pointed it out because I didn't want you to be buried bellow another layer of complexity just because of our request).

> Plus, create a user for review.rdoproject.org. It's easier to review patches that way.

Don't expect me to create an account on another service when I deal with Fedora packages, the canonical source of a Fedora package is https://src.fedoraproject.org - it supports pull requests and works great for reviewing patches.

Please read: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity or https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Spec_Maintenance_and_Canonicity (some content, different location)

Either way, is there any expected date when this reaches Fedora? It has been a month since the initial request.


Comment 12 Miro Hrončok 2018-11-05 20:08:28 UTC
I cannot reproduce this on Fedora 28 either:

<mock-chroot> sh-4.4# LANG=C.utf-8 rpmspec -P python-designateclient_new-5c8eb0f804b26424f0ce5c98c185b30b57528858.spec | grep site-packages/designateclient
%exclude /usr/lib/python3.6/site-packages/designateclient/tests

Here is a scratchbuild of http://logs.rdoproject.org/20/17220/2/check/legacy-DLRN-rpmbuild-fedora/f1d38d3/buildset/fedora/repos/f0/b7/f0b7eb4d8c90ef516174538025629d8458d4180b_dev/python-designateclient-2.11.0-0.20181102184640.f0b7eb4.fc28.src.rpm





It fails with openstack-macros not being present. If I remove that dependency, it fails on %py_req_cleanup not being defined. That was smoking gun for me, openstack-macros might have some Python macros that break things.

And yes, you redefine Fedor macros in https://github.com/openstack/rpm-packaging/blob/master/openstack/openstack-macros/macros.openstack-singlespec

Please don't try to push this into Fedora or you'll break existing packages that work.

Comment 13 Miro Hrončok 2018-11-26 11:40:54 UTC
This was filled ~2 months ago and is in MODIFIED state for weeks, yet the Fedora package has last commit 3 months ago. What can I do to move this forward?

Note that we need this change in Fedora and not RDO/whatever.


Comment 14 Alfredo Moralejo 2018-12-03 10:19:46 UTC
@Victoria if it's ok for you I'll push a new build with conditionals to remove python2 subpackages aligned with what we are doing with other openstack clients. Note that we are removint python2-osc-lib and need to fix all those which depend on it.

Comment 15 Victoria Martinez de la Cruz 2018-12-03 14:12:23 UTC
Merged PR submitted by @amoralej. Thanks.

Comment 16 Miro Hrončok 2019-03-08 10:31:17 UTC
Thank You.

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