On 3/13/19 9:30 AM, Stephen John Smoogen wrote:
Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W
George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7. They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.
The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
Please heavily test them by doing the following:
Stage 1 Testing
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
Install various packages you would normally use
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 2 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python34
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 3 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python36
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
This should cover the three most common scenarios. Other scenarios
exist and will require some sort of intervention to work around. We
will outline them as they come up.
I've come across 3 packages that cause problems with the
python34-python36 migration:
python36-pyflakes: Running 'yum install python36-pyflakes' on a system
with python34-pyflakes installed results in a conflict due to the
python3-prefixed executable and man pages:
Transaction check error:
file /usr/bin/pyflakes-3 from install of
python36-pyflakes-1.6.0-4.el7.noarch conflicts with file from package
python34-pyflakes-1.3.0-2.el7.noarch
file /usr/share/man/man1/pyflakes-3.1.gz from install of
python36-pyflakes-1.6.0-4.el7.noarch conflicts with file from package
python34-pyflakes-1.3.0-2.el7.noarch
python36-future, python36-pylint: These explicitly "Obsolete:" the
python34 versions. Presumably this is to avoid the conflict with the
man pages, like the above problem with pyflakes.
Forcing the removal of the python34 version of the packages can be
problematic for user communities (such as mine) that are still working
to migrate their code from python34 to python36.
I can submit patches to resolve this, but I wonder what the policy
should be for auto-removing the python34 equivalents?
--Wart