Re: [EPEL-devel] Moving EPEL7 to python3.6
> "NG" == Neal Gompa writes: NG> Wait, we can do that? I thought we couldn't use the exception NG> process for this? Well, the idea is that you don't need a separate review just to import a different version of the same package. So foo and foo1.2 (the 1.2 version) or python-abc and python36-abc (the python 3.6 version). The package itself is going to be pretty much the same thing in either case. - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org 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/python-devel@lists.fedoraproject.org
Re: [EPEL-devel] Moving EPEL7 to python3.6
On Tue, Oct 23, 2018 at 1:28 PM Jason L Tibbitts III wrote: > > > "OP" == Orion Poplawski writes: > > OP> - Can we make epel7-py36 branches, and somehow have > OP> %python3_version, et. al. be 3.6 for those builds? > > I can't think of any way to do that without extra magic. And if you > require something in the spec, you might as well just hardcode it. > > OP> - Can we just make it easier for people to create python3X- packages > OP> from existing python3- or python3(X-n)- packages? And just drop the > OP> whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ > OP> *.spec does 90% of the work? > > Right now the process is: > > fedpkg request-repo --summary "Summary of foo" --exception python36-foo > fedpkg request-branch --repo python36-foo epel7 > (wait) > fedpkg clone python36-foo > cd python36-foo > fedpkg retire "This is an EPEL-only package" > fedpkg switch-branch epel7 > > And then copy in your spec and sources, edit and go. There is no need > for a package review. > > That's certainly a few steps but far from the worst process in the > distro. What could we do to make it easier? > Wait, we can do that? I thought we couldn't use the exception process for this? -- 真実はいつも一つ！/ Always, there's only one truth! ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org 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/python-devel@lists.fedoraproject.org
Re: [EPEL-devel] Moving EPEL7 to python3.6
> "OP" == Orion Poplawski writes: OP> - Can we make epel7-py36 branches, and somehow have OP> %python3_version, et. al. be 3.6 for those builds? I can't think of any way to do that without extra magic. And if you require something in the spec, you might as well just hardcode it. OP> - Can we just make it easier for people to create python3X- packages OP> from existing python3- or python3(X-n)- packages? And just drop the OP> whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ OP> *.spec does 90% of the work? Right now the process is: fedpkg request-repo --summary "Summary of foo" --exception python36-foo fedpkg request-branch --repo python36-foo epel7 (wait) fedpkg clone python36-foo cd python36-foo fedpkg retire "This is an EPEL-only package" fedpkg switch-branch epel7 And then copy in your spec and sources, edit and go. There is no need for a package review. That's certainly a few steps but far from the worst process in the distro. What could we do to make it easier? - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org 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/python-devel@lists.fedoraproject.org
Re: [EPEL-devel] Moving EPEL7 to python3.6
On 10/19/2018 01:22 PM, Stephen John Smoogen wrote: Hi, EPEL is a set of packages which work for CentOS and RHEL versions 6 and 7. In the version 7, we are currently using python34 and would like to move this to python36. In doing so, we need help in both our packaging rules and in updating a lot of packages to work for python36. First problem: Packaging rules. Because there could be updates of python versions from 3.4 to 3.6 or 3.8, we wanted to make clear what python was used for any particular library. This would make it so someone needing python-bottle did not end up with one packaged with python-3.6 installed on a python-3.4 system. So we wanted the names to be more specific than python3 and went with naming all the sub packages python34 or python36. However, this was decided a while ago and it may not be the best convention to use or one that the current python sig would like us to use. I would like to get a naming convention cleared up and documented so when we do a mass rebuild that the packages come out with either a python3- or python36- If you are going to be having different versions of python3 over the life of a release, I think it's imperative that it be explicit what version of python 3 a package is for. Otherwise lies madness. Second problem: When to do this update We had been looking to do this in October, but it may make more sense to do this in November after Fedora29 has shipped so that people can help focus on this versus anything F29 related. It also gives us some lead time to write blogs/magazine items. How does 2018-11-14 sound? Third problem: Updating and rebuilding packages to work with python36 Below are the list of packages I found which were making python34- packages currently in EPEL-7. In updating to python36, I would like to have a combined Virtual Fedora Activity Day where we work together on IRC. First we would get any scripts ready and then work with release engineering to change macros in epel-macros to point to the correct versions of python and any name changes. We would then do a mass release bump and rebuild all the packages against python3.6. As problems are found during that day we would make appropriate changes and fix. This might take 2 gos. The biggest issue I have run into with Python 3 packaging in EPEL is version lock. Python modules (like most software) have atrocious backwards compatibility. For example, we have python3-scipy at version 0.18.1. If we add a python3_other_pkgversion package to it for python36, we get python36-scipy-0.18.1 whereas we really want python36-scipy-1.15.2 (not just to get the latest and greatest - though that is important - the old version of the module just may not work with the latest python). We can't update to that though in the python34 stack or we'll break things. This plays havock with the original vision of just flip a macro switch and rebuild everything, which means rolling out a new python version will take time and consideration of each package. So I think we need another approach. Some ideas: - Can we make epel7-py36 branches, and somehow have %python3_version, et. al. be 3.6 for those builds? - Can we just make it easier for people to create python3X- packages from existing python3- or python3(X-n)- packages? And just drop the whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ *.spec does 90% of the work? Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org 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/python-devel@lists.fedoraproject.org
