So, a package I help maintain, python-dns is now provided by Red Hat. So I thought, "OK, I'll still build the python34 package to help in that effort". But the problem with that is, per the EPEL 7 in Python 3 Plan Draft (1), if Red Hat provides the package, the SRPM can't use the same name. I can see the merit there. The problem is that in Fedora, a SRPM name needs to match the git repo name. So, yes, I could ask for a python3-dns package to be setup, but that creates two problems. The first, keeping the EPEL-only repo in sync with the main repo. The second, Differentiating between the python3 package for Fedora which is in the python-dns git repo and the python3 package for EPEL which, according to the guideline, would be in python3-dns. Ideally, I'd be able to maintain everything in the main git repo and use one spec file cloned from master. That's not too difficult except the Fedora build system won't build a package if it can't find the package (based on the SRPM name) in the database. I don't see a clean solution which makes me very hesitant to preemptively put out python34-dns for EPEL7. Which is part of the whole problem with python34 on EL7, there are no packages. If you build it, they will come, otherwise everyone stands around complaining it's not built. Am I missing something? Avram 1: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Packaging_Paral...

On 28 March 2016 at 10:07, Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin <aviso(a)rockhopper.net&gt; wrote: >> >> So, a package I help maintain, python-dns is now provided by Red Hat. So I >> thought, "OK, I'll still build the python34 package to help in that effort". >> But the problem with that is, per the EPEL 7 in Python 3 Plan Draft (1), if >> Red Hat provides the package, the SRPM can't use the same name. I can see >> the merit there. The problem is that in Fedora, a SRPM name needs to match >> the git repo name. So, yes, I could ask for a python3-dns package to be >> setup, but that creates two problems. The first, keeping the EPEL-only repo >> in sync with the main repo. The second, Differentiating between the python3 >> package for Fedora which is in the python-dns git repo and the python3 >> package for EPEL which, according to the guideline, would be in python3-dns. >> >> Ideally, I'd be able to maintain everything in the main git repo and use one >> spec file cloned from master. That's not too difficult except the Fedora >> build system won't build a package if it can't find the package (based on >> the SRPM name) in the database. >> >> I don't see a clean solution which makes me very hesitant to preemptively >> put out python34-dns for EPEL7. Which is part of the whole problem with >> python34 on EL7, there are no packages. If you build it, they will come, >> otherwise everyone stands around complaining it's not built. >> >> Am I missing something? >> >> Avram >> >> 1: >> https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Packaging_Paral... >> > > Couldn't you just disable the python2 module build for EPEL7? That > should eliminate the conflict. > > The python2 module is built in RHEL/CentOS and not in EPEL so he can't disable it. The only way currently it can be 'built' for EL-7 is to put it in the python3-dns name and do the review...

Come join us ... https://admin.fedoraproject.org/pkgdb/packages/?motif=python3-*&branc...