Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Yesterday an update to EL7 EPEL brought in Python 3.6. The automatic update switches the default symlink from python34 to python36. However, the update did not pick up all additional Python dependencies, like in our case python34-PyYAML was not updated so all scripts using "import yaml" started failing because the system was executing /usr/bin/python3 with the new python3.6, but the installed python3-PyYAML package was only present for python3.4. Manually installing python36-PyYAML is required as a workaround, but a general system update should not be breaking the internal dependencies. Version-Release number of selected component (if applicable): python34-* auto updated to python36-* How reproducible: always Steps to Reproduce: 1. run centos 7 with epel enabled and with the older python3 (that's python 3.4 installed) 2. create a script with #!/usr/bin/python3 or env python3, and add "import yaml" to the script. 3. For yaml support install python34-PyYAML 4. Run yum update, and try to run the script Actual results: Script starts failing with missing yaml module Expected results: python update to 3.6 should also install other python modules that exist in the system and pertain to the already installed minor version, so when python 3.4 is updated to 3.6, PyYAML3.6 should be installed if PyYAML3.4 already is in the system. Additional info:
I don't think there is anything we can do about this. If you have created script that uses /usr/bin/python3, you are not being specific about what version of python3 you require. If you had used #!/usr/bin/python3.4 your script would continue to work. It is unfortunate, but there is no way for rpm/yum to know what python modules for what versions of python you need and automatically update them.
It would be great to actually stop providing minor version specific python packages. python3-PyYAML would be the answer to this bug. There is a list of python34-* mirrored by an even larger list of python36-* packages in EPEL, why maintain all of that, and break functionality for people every time you decide to move the python executable ahead? In my case, I also use python3-pyudev, which dragged in python3.6 during update. If there was also a python3-PyYAML, it would also have been updated, and I wouldn't even have noticed the change.
I realize it's not a great user experience, but it's what we have. As for the various python3-X package in EPEL7 like python3-pyudev, they aren't following the EPEL packaging guidelines.
Thanks for clarifying that