Description of problem: There is a well-known tendency nowadays among upstream vendors in switching from python2 to python3. Sometimes, it causes problems since epel7 lacks python3 extensions, so old software cannot be updated, and new packages cannot be provided in epel7. Such demand will be only increasing eventually. Currently, I need python34-msgpack packaged in epel7, to provide some new python3-based packages in epel7. Proposal: The technical details on how to provide python3 support in epel have been recently discussed in fpc ticket [1], there is a more detailed workflow [2]. To make long story short, the current spec file in epel7 branch can be modernized in order to provide both python- and python34- versions for epel7. That would be enough for this moment, and doesn't require a lot of changes. Later on, when fancy macros are available and stable enough, we can generalize spec file in epel7 and fXX branches back again using these macros. [1] https://fedorahosted.org/fpc/ticket/567 [2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
I have started looking into this but it fails to build due to missing dependencies in EPEL7: http://koji.fedoraproject.org/koji/taskinfo?taskID=12202013 The exact error being: DEBUG util.py:393: Error: No Package found for python3-devel DEBUG util.py:393: Error: No Package found for python3-pytest DEBUG util.py:393: Error: No Package found for python3-setuptools Attached is a patch to the current spec, adjusting it for the new guidelines and preparing for py3 on epel7.
Created attachment 1106082 [details] Update spec file and prepare for py3 on epel7
Ok, I initially meant that we can do the changes in epel7 branch only, but you decided to change the spec globally ;-) Although, even with the changes it should be unusable right now. 1) First, python-setuptools package should have "python34-setuptools" build in epel7 right the same way we've been discussing here. The same is for pytest and "python34-pytest". In other words, we need to start modernizing py3 stack in epel7 from these packages. They also have some prerequisites so it will take some time when someone is in business with. 2) There is no need to keep the block below in the spec anymore, and "with_python3" global: %if 0%{?fedora} +# || 0%{?rhel} && 0%{?rhel} >= 7 %global with_python3 1 -- since we know in advance that all branches that adopt this updated spec have python3. Old fXX branches and el{5,6} just won't get this spec. The same also applicable to el6-specific stuff: %if 0%{?rhel} && 0%{?rhel} <= 6 ... 3) We need to use some "ifdef-spaghetti" to determine python package prefix ('python3' for fXX, 'python34' for epel7 currently). Later it can be replaced with "fancy macros" that will generalize things, but now they're not ready yet, so something like: BuildRequires: python2-devel %if 0%{?fedora} BuildRequires: python3-devel %else BuildRequires: python34-devel %endif -- is only an option now.
P.S. I'm not filling bugs against other components involved since I don't know how many people are generally interested in, and collecting feedback. I'm planning to broaden epel7 py3 stack gradually if there are some enthusiasts who could help out with.
Regarding the points you made: 1) I do not know that py3 packages in EPEL7 will be for sure prefixed with the full python version (ie: python34-foo/python35-bar), and as far as I can see, it is not really clearly defined yet. 2) That depends if the maintainers want to maintain 1 spec for all branches which I know is something many people like to do. 3) Something for later then :) There are definitively people interesting in python3 on EPEL7, the Fedora infrastructure started a discussion around this not so long ago, so you will be able to find help :)
As for the points: 1) In my opinion they should be prefixed, since theoretically there could be several py3 parallel stacks in epelXX, for example: python34, python35, etc. For Fedora it's not actual since it has less lifetime and has only one py3 stack, so it can just stick to python3. 2) Yeah, but it would require even more "ifdef-spaghetti" ;-) At some point we could just support "upgrade-able" branches, but sure it's a matter of taste.
My experience is that most of spec files with py3 enabled for epel7 look like this one: http://pkgs.fedoraproject.org/cgit/python-setuptools_scm.git/tree/python-setuptools_scm.spec so while having the stack prefixed is something to be thought about, in practice I see it otherwise.
Well, the epel7 branch hasn't been populated for this package yet, so in general the spec can be changed in the future. But yes, all in all the question about prefixes in epel should be definitely clarified.
EPEL7 python3 package will definitely have a python3X prefix. https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL is what we have at the moment. One problem is that %{python3_pkgversion} is not defined in the Fedora buildroots, but I'm hoping to fix that soon. Reviews for setuptools and pytest are underway. More review help needed.
Also, there is a copr here: https://copr.fedoraproject.org/coprs/g/python/python3_epel7 that anyone in the python sig should be able to send builds to.
Created attachment 1119632 [details] epel7 compatibility patch Since all py3 deps have been recently resolved in epel7, there is a patch to the current spec. Please apply to rawhide, merge to epel7 branch and rebuild. Koji scratch builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=12740350 (Rawhide) https://koji.fedoraproject.org/koji/taskinfo?taskID=12740356 (EPEL 7) Notes: 1) f22, f23 both don't have `%{python3_pkgversion}` macros, so don't merge there. Generally, these branches can go without further updates already (or macros can be backported if needed); 2) el6 support has been dropped with a recent commit from Fabian, so just a notification: el6 also cannot be directly updated with branch merge anymore; 3) `%with_python3_other` isn't considered yet, will be introduced when epel7 py3 version transition process becomes actual.
Since there's no changes, I've requested commit access to update the package.
python-msgpack-0.4.7-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bf6f33ddfc
python-msgpack-0.4.7-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-4986bb63e5
python-msgpack-0.4.7-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bf6f33ddfc
python-msgpack-0.4.7-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-4986bb63e5
python-msgpack-0.4.7-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
python-msgpack-0.4.7-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.