Learn more about these different git repos.
Other Git URLs
python-urllib3 has been retired on epel7 because RHEL/CentOS 7 ships it. However, it only ships the Python 2.7 version. I am working on bringing more packages to the new Python 3.4 stack in EPEL7, including this one, so I would like to un-retire it.
I will restore the same version that is used in RHEL7/CentOS7 and change the specfile so that the Python 2 version is not build, in order to avoid a potential conflict with the base distro.
Hum, I am pretty against this... IMHO we should call the epel only python3 package 'python3-urllib3' so it doesn't conflict at all with rhel.
If we call it by the same source package name it will. It will break everything that requires the python2 version at build time.
Is there any reason we couldn't call this python3-urllib3?
No problem at all, let's call it python3-urllib3. However, I can't see how it would break everything that requires the python2 version at build time, could you explain with some details?
This has some examples: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/4EA4NDU4QCENJKL42ZBHGE5KXRJXJWQI/
Basically koji operates on source packages. So if there's a python-urllib3 in epel it will use that and all it's binary packages that it makes. It will see there's a python-urllib3 in rhel, but ignore it and all it's binary packages. If the EPEL one doesn't make python2-urllib3 or python-urllib3 then packages that need that to build will fail. Additionally, if you do build those they will completely override the RHEL versions.
So, if we stick with a source package name that doesn't overlap with rhel we are much better off.
OK, I'll keep that in mind, thanks for explaining.
Metadata Update from @abompard: - Issue set to the milestone: Fedora 25 Alpha
Login to comment on this ticket.