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
python2-altgraph is scheduled for removal. python2-sqlalchemy_schemadisplay is unfortunately required by bodhi, as said.
https://src.fedoraproject.org/rpms/pydot/pull-request/1
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.
What kind of coordination do you have in mind?
(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.
> 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.
(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.
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
(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!
> 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.