Description of problem: The 'python34-pycurl' package has disappeared after the addition of python36 to EPEL. Version-Release number of selected component (if applicable): N/A How reproducible: Always Steps to Reproduce: 1. Do 'yum search python34-pycurl' 2. 3. Actual results: [root@rivtest ~]# yum search python34-pycurl Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.team-cymru.com * epel: mirror.cogentco.com * extras: mirror.siena.edu * updates: repos.mia.quadranet.com Warning: No matches found for: python34-pycurl No matches found Expected results: [root@elastigirl rivendell]# yum search python34-pycurl Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.wdc1.us.leaseweb.net * epel: mirror.cogentco.com * extras: mirror.wdc1.us.leaseweb.net * updates: mirror.wdc1.us.leaseweb.net ========================= N/S matched: python34-pycurl ========================= python34-pycurl.x86_64 : Python interface to libcurl for Python 3 Name and summary matches only, use "search all" for everything. Additional info: Supercedes ticket 1705286
Is there any particular reason why you cannot shift to using python 3.6?
python-bottle-0.12.13-3.el7 python3-pycurl-7.43.0-7.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-29a9c757ec
python-bottle-0.12.13-3.el7, python3-pycurl-7.43.0-7.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-29a9c757ec
(In reply to Orion Poplawski from comment #1) > Is there any particular reason why you cannot shift to using python 3.6? They could. However, consider the following scenario: BEFORE UPDATE 1) End user has installed python34, along with various other dependent modules available in EPEL. 2) End user adds his own site-specfic modules in the 3.4 modules path. 3) End user uses a bang path of '#!/usr/bin/python3' for his local scripts. AFTER UPDATE The bang path in the local scripts now instantiates Python 3.6, not 3.4, which means that all of his local modules cannot be found since as they are in the 3.4 modules path. Train wreckage ensues. SUMMARY A simple on-line update --e.g. 'yum -y update' -- should not silently break applications!
Yeah, it's not a great situation. I think the moral of the story is, if you are depending on python 3.4, use /usr/bin/python3.4. /usr/bin/python3 is not stable.
Agreed. Hence, the need for python34-foo packages that do not evaporate when EPEL adds a newer version of Python.
Well, the python34-pycurl package didn't evaporate from the installed machine, right? It was just new deployments which were affected. Which is a pain, I grant you. Anyway, update is in testing now.
Correct. It's new installations that are the problem. If RPMs for the application have 'Requires:' values for modules in the previous Python stack that have gone missing after the EPEL update, they break when a user goes to install them.
python-bottle-0.12.13-3.el7, python3-pycurl-7.43.0-7.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.