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@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > 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 _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
