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_Parallel...
On 28 March 2016 at 09:00, Avram Lubkin aviso@rockhopper.net 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?
You forgot the next corollary: If you build it, it will need to be rebuilt for python35/36/37 by the time you get to it.
Avram
1: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Packaging_Parallel...
python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject....
On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin aviso@rockhopper.net 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_Parallel...
Couldn't you just disable the python2 module build for EPEL7? That should eliminate the conflict.
On 28 March 2016 at 10:07, Neal Gompa ngompa13@gmail.com wrote:
On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin aviso@rockhopper.net 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_Parallel...
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...
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject....
On Mon, Mar 28, 2016 at 12:31 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 28 March 2016 at 10:07, Neal Gompa ngompa13@gmail.com wrote:
On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin aviso@rockhopper.net 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_Parallel...
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...
So he can't keep the same spec, but simply disable the python2 module subpackage and build and only build the python3 one for EPEL7? That seems rather off.
On 03/28/2016 09:00 AM, Avram Lubkin 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?
Not really, although with git remotes I imagine you could pull changes from the python-dns git repo into the python3-dns repo if desired.
Come join us ...
https://admin.fedoraproject.org/pkgdb/packages/?motif=python3-*&branches...
Hello there,
On Mon, Mar 28, 2016 at 11:37 PM, Orion Poplawski orion@cora.nwra.com wrote:
Come join us ...
https://admin.fedoraproject.org/pkgdb/packages/?motif=python3-*&branches...
A bit off-topic.. Orion, could you proceed with python3-Cython? ( https://bugzilla.redhat.com/show_bug.cgi?id=1297977) It would be nice to have it in addition to the package collection above ;-)
python-devel@lists.fedoraproject.org
-
Avram Lubkin -
Denis Fateyev -
Neal Gompa -
Orion Poplawski -
Stephen John Smoogen