Bug 1637711

Summary: python2-pydot was dropped while it still has dependent packages
Product: [Fedora] Fedora Reporter: Randy Barlow <rbarlow>
Component: pydotAssignee: Randy Barlow <rbarlow>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: besser82, mhroncok, pviktori, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-15 17:48:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Randy Barlow 2018-10-09 21:03:25 UTC
Description of problem:
The Python 2 version of pydot was recently removed[0], but it still has two other RPMs that depend on it (and other RPMs depend on those RPMs, such as Bodhi, which BuildRequires python2-sqlalchemy_schemadisplay):

$ dnf repoquery --whatrequires python2-pydot
python2-altgraph-0:0.12-16.fc29.noarch
python2-sqlalchemy_schemadisplay-0:1.3-6.fc30.noarch

This was likely done for the Fedora 30 Python 2 change[1], but a key element of that change is that packages should be removed "unless some other package(s) depends on them."

Please bring the Python 2 version of pydot back until it has no dependent packages. Thanks!


Additional info:
[0] https://src.fedoraproject.org/rpms/pydot/c/30aab8872aec9cb7511a5464f4d276045f82d031?branch=master
[1] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

Comment 1 Miro Hrončok 2018-10-10 13:11:14 UTC
python2-altgraph is scheduled for removal.

python2-sqlalchemy_schemadisplay is unfortunately required by bodhi, as said.

Comment 3 Tom "spot" Callaway 2018-10-15 15:04:46 UTC
This feels like a rigged carnival game, to be honest. We're killing Python 2, except for our _own_ in house developed apps, which still depend on Python 2, and which we cannot remove, so we aren't really killing Python 2.

I've merged the PR request, but I really wish we had better coordination around this.

Comment 4 Petr Viktorin (pviktori) 2018-10-15 15:12:20 UTC
What kind of coordination do you have in mind?

Comment 5 Tom "spot" Callaway 2018-10-15 15:17:43 UTC
(In reply to Petr Viktorin from comment #4)
> What kind of coordination do you have in mind?

Is "any" a valid reply? ;)

Seriously, though, if there are known packages in the Python 2 stack that aren't going to be removed anytime soon (e.g. bodhi), blocking the python2 removal bugs for dependent packages against a blocker bug for those items seems a logical way to minimize disruption.

Comment 6 Miro Hrončok 2018-10-15 15:30:13 UTC
> Seriously, though, if there are known packages in the Python 2 stack that
> aren't going to be removed anytime soon (e.g. bodhi), blocking the python2
> removal bugs for dependent packages against a blocker bug for those items
> seems a logical way to minimize disruption.

Note that we are only opening bugz for packages that can be removed right now.
If a package is required, we do not open any bug at all.
We do it this way to minimize disruption.

I don't recall opening a removal request for python2-pydot.
If it actually was opened, that is a serious problem.

Comment 7 Tom "spot" Callaway 2018-10-15 15:33:09 UTC
(In reply to Miro Hrončok from comment #6)

> Note that we are only opening bugz for packages that can be removed right
> now.
> If a package is required, we do not open any bug at all.
> We do it this way to minimize disruption.
> 
> I don't recall opening a removal request for python2-pydot.
> If it actually was opened, that is a serious problem.

Okay, then this one was on me. We needed python3 support for pydot, and I assumed that _all_ python 2 packages needed to go away for F30, so I killed two birds with one stone.

Comment 8 Miro Hrončok 2018-10-15 15:36:43 UTC
As much as I'd like to see all python2 packages away from F30, we realize that this is not possible (lot of infra stuff, qa stuff, nodejs, chromium, fedora-packager...).

What happens for F30 is:

"(Sub-)packages only providing python2 importable modules without additional functionality will be removed from Fedora **unless some other package(s) depends on them**."

https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

Comment 9 Randy Barlow 2018-10-15 17:48:46 UTC
(In reply to Tom "spot" Callaway from comment #5)
> Seriously, though, if there are known packages in the Python 2 stack that
> aren't going to be removed anytime soon (e.g. bodhi), blocking the python2
> removal bugs for dependent packages against a blocker bug for those items
> seems a logical way to minimize disruption.

FWIW, I anticipate switching Bodhi server to Python 3 for Bodhi's next release, which should happen "soon" (probably 2-4 weeks after F29 release). The client is already Python 3.

Thanks for merging my patch!

Comment 10 Petr Viktorin (pviktori) 2018-10-16 09:43:35 UTC
> As much as I'd like to see all python2 packages away from F30, we realize that this is not possible (lot of infra stuff, qa stuff, nodejs, chromium, fedora-packager...).

FWIW, one of the bigger reasons for the mass dropping is to filter these out, so the list of remaining py2-only stuff becomes a list of where to focus py3 porting effort.


> Okay, then this one was on me. We needed python3 support for pydot, and I assumed that _all_ python 2 packages needed to go away for F30, so I killed two birds with one stone.

Some upstreams are switching to Python3 only, and we need the latest version in Fedora. In that case, it's possible split the python2- subpackage out into its own component/SRPM. (Python SIG has a a blanket FPC exception for these cases, to reduce the review bureaucracy.)


> FWIW, I anticipate switching Bodhi server to Python 3 for Bodhi's next release, which should happen "soon" (probably 2-4 weeks after F29 release). The client is already Python 3.

Looking forward to that!
We'll pick the change up and file bugs for all the new leaves.