Description of problem: python2-crypto from EPEL 7 is attempting to obsolete python-crypto from CentOS Extras repo. Not normal expected behavior. CentOS 7 Extras: Name : python-crypto Arch : x86_64 Version : 2.6.1 Release : 1.el7.centos Size : 2.3 M Repo : installed From repo : extras Summary : Cryptography library for Python URL : http://www.pycrypto.org/ License : Public Domain and Python Description : PyCrypto is a collection of both secure hash functions (such as MD5 and : SHA), and various encryption algorithms (AES, DES, RSA, ElGamal, etc.). EPEL 7: Name : python2-crypto Arch : x86_64 Version : 2.6.1 Release : 9.el7 Size : 475 k Repo : epel/x86_64 Summary : Cryptography library for Python 2 URL : http://www.pycrypto.org/ License : Public Domain and Python Description : PyCrypto is a collection of both secure hash functions (such as MD5 and : SHA), and various encryption algorithms (AES, DES, RSA, ElGamal, etc.). : : This is the Python 2 build of the package.
Moving to python-crypto component and adding paul since he made the changes that caused this. :)
Why is this not normal expected behavior? EPEL's conflicting packages policy (https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages) only states that packages in the base RHEL channels can't be replaced by EPEL packages. I wasn't aware that there was any policy regarding CentOS Extras. Looking at the original CentOS Extras package, it appears to be a clone (same spec) as the previous python-crypto release in EPEL, so any update I did of the python-cyrpto package in EPEL (e.g. for a security fix) would also have replaced the CentOS Extras package. I modernized the spec to use the now-standard python{2,3}- naming when adding Python3 support, and that resulted in the provides/obsoletes to replace the previous python-crypto package in EPEL. Given that the CentOS Extras package was identical to the EPEL one, I would say that its obsoletion was the intended result. Is there any technical issue with the new package not working in exactly the same way as the old one? If it's just a policy issue at your site that you want CentOS Extras packages to prevail over EPEL packages, that might be best done via some protection mechanism in yum. I suspect that many other packages in EPEL could potentially replace CentOS Extras ones, given that there's no policy I'm aware of that forbids them to do so.
I'm not saying at all that there is a functionality issue or a policy issue, I just haven't come across a case of an EPEL package replacing a system provided package (even from extras) before. I wasn't sure if this was an actual bug, an oversight, or something to be concerned about at all. I opened the ticket so that the issue would be documented. I appreciate your explanation, and will bring it up with CentOS as well.
Some background: python-crypto was added into CentOS-Extras to bootstrap some dependencies for some of our build tools. We plan on tracking the EPEL packages for these dependencies in CentOS-Extras (for our developers who choose to not have EPEL enabled). EPEL is not restricted by policy from updating packages in CentOS-Extras.
Good to know, thanks.