I thought of a solution, but it a purely technological one that ignores any business relationship details, as they are above my pay grade: if VPP were part of the EPEL distribution rather than directly part of RHEL/CentOS, then there would be no problems!
Burt On Mon, Sep 25, 2017 at 7:31 AM, Thomas F Herbert <therb...@redhat.com> wrote: > > > On 09/25/2017 05:02 AM, Marco Varlese wrote: > > Thanks for the thorough explanation Klement!Based on that, I think (2) is > still the better option for the current situation... > > Tom, how would that sound to you? > > > "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" > <ksek...@cisco.com> <ksek...@cisco.com> 09/25/17 10:40 AM >>> > > Quoting Marco Varlese (2017-09-25 10:26:50) > > Hi Klement, > > > "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" > <ksek...@cisco.com> <ksek...@cisco.com> 09/25/17 9:33 AM >>> > > At the time of creating this patch, epel was part of Makefile and > python34 was installed as dependency from that repo. > (see https://gerrit.fd.io/r/#/c/6983/53/Makefile) > At later time, the epel stuff disappeared and with it also > the possibility to add python34 as a centos dependency - commit > bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out > in discussion with Neale, but I didn't get a chance to test whether > centos works or not before it was merged. > > That's OK. You would have had to test with a system without EPEL Repo > enabled to discover this problem. > > I should have paid closer attention when this patch was first discussed in > May. Please add me as a reviewer for patches that have implications for RPM > packaging and requirements. > > I think it would be nice though to update other scripts too so to have one > single python version used across the board. > Currently, to build VPP on our distribution I need to require both python and > python3 packages since some python scripts use one rather than the other. > Aligning python versions would make downstream consumption better I believe. > Is this something which will/could be done? > > See below. > > > As for the solution, I can think of 3 options: > > 1.) require python3 (which has been around for some ~9 years now) > 2.) disable generation of the C (and C++) API if python3 is not detected > > I think this would be a fair compromise for distros not supporting (yet) > python3. However, I am not sure how this would result in the VPP CI... > wouldn't this break all tests running over those API? > > Tests are python2.7 because scapy wasn't python3 capable when we > designed the test framework. > > These are language bindings, not different API calls. Only test_vapi, > which tests that the language bindings of different types (simple > request, dump, event, etc.) work would have to be disabled. > > I think this is a good interim work-around until the distros have Python3. > I can submit another patch to allow this the inclusion would be enabled as > a default but could be disabled only in downstream builds in RHEL and > Centos 7. > > When will we have tests in CSIT that use the C/C++ APIs in 17.10? > > Neale, are we planning to cherry-pick this patch into 17.10? > > Do we have yet tests in CSIT that use the C/C++ APIs in 17.10? > > > > 3.) convert the script to python2.7 (which is in the opposite direction of > where we would want to go wrt python version) > > Thanks, > Klement > > Cheers, > Marco > > Quoting Thomas F Herbert (2017-09-23 15:55:10) > > All: > > Commit 8f2a4ea, Gerrit, [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C > API" > > introduces a dependency on Python 3 and breaks downstream builds for > Centos. > > Unfortunately, neither RHEL nor Centos currently support Python 3. > > Most VPPers are probably building with EPEL repo so this problem didn't > show up until now but actually there is no dependency on EPEL in the > Makefile or spec file. > > If anybody can suggest a solution short of pushing Python 3 into the > downstream repos, I am open to suggestions. > > --Tom > > -- > Thomas F Herbert > NFV and Fast Data Planes > Office of Technology > Red Hat > > References > > Visible links > 1. https://gerrit.fd.io/r/#/c/6983/ > > _______________________________________________ > vpp-dev mailing > listvpp-...@lists.fd.iohttps://lists.fd.io/mailman/listinfo/vpp-dev > > > -- > *Thomas F Herbert* > NFV and Fast Data Planes > Office of Technology > *Red Hat* > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
