I looked in http://resources.ovirt.org/pub/ovirt-4.1/rpm/el7/x86_64/ and in https://access.redhat.com/downloads/content/package-browser. There is a python-ovirt-engine-sdk4 package, but no python34-ovirt-engine-sdk4. Documentation and tools for dual-version packaging is easy to find, look for example at: http://python-rpm-porting.readthedocs.io/en/latest/tools.html
We don't build the SDK for Python 3 and CentOS 7 because CentOS 7 doesn't support Python 3 unless you add optional repositories like EPEL. Same applies to RHEL 7. However we do build the Python 3 RPM for Fedora 24 and 25. Here is the .spec file that we use: https://github.com/oVirt/ovirt-engine-sdk/blob/master/packaging/spec.fc24.in Here is the latest RPM for Fedora 24, for example: http://resources.ovirt.org/pub/ovirt-4.1/rpm/fc24/x86_64/python3-ovirt-engine-sdk4-4.1.0-1.fc24.x86_64.rpm It would be useful to build the RPM for CentOS 7, using EPEL, but we need to check if requiring the EPEL repositories is oVirt projects is acceptable. I think it shuldn't be a problem, and adapting the .spec should be easy. In the Red Hat package browser you will never find that Python 3 package, because it isn't officially supported by Red Hat.
Checking the source of the 'ovirt-release' package, I see that we do use EPEL already, but only with a limited set of packages: https://github.com/oVirt/ovirt-release/blob/ovirt-4.1/ovirt-el7-x86_64-deps.repo.in#L1-L9 That means that in order to be able to distribute the Python 3 RPM we would have to add to that list all the 'python34*' packages, otherwise installation would fail. However, if someone is interested in using the Python 3 RPM, then I assume that she/he would have already enabled the EPEL repository explicitly, in order to install the 'python34' package. So maybe we could just build and publish the SDK RPM without modifying the 'ovirt-release' RPM.
It won't work as is in RHEL/Centos: It says: Requires: libxml2 Requires: python3 Requires: python3-enum34 Requires: python3-pycurl Requires: python3-six But on a Centos 7, with epel installed: # yum install python3 python3-enum34 python3-pycurl python3-six No package python3 available. No package python3-enum34 available. No package python3-pycurl available. No package python3-six available. And python3-enum34 is useless on a python3 installation as it's a backport of enum from python3 to python2. I attached a working spec file, tested on Centos7. I'm not sure about the "supported" thing for any sdk. People would like to use it on various platform, to integrate ovirt with there tools. I need it for example to integrate oVirt with Rundeck jobs. So the sdk should be part of epel, in both versions.
Created attachment 1285836 [details] A spec file for dual packaging of sdk on Centos 6/7.
(In reply to Juan Hernández from comment #2) > However, if someone is interested in using the Python 3 RPM, then I assume > that she/he would have already enabled the EPEL repository explicitly, in > order to install the 'python34' package. So maybe we could just build and > publish the SDK RPM without modifying the 'ovirt-release' RPM. I agree, it's to install it on server installed without the full ovirt stack. Just to use it for custom services.
We don't expect the Fedora RPM to work in CentOS. I pointed to it just to let you know that we do support Python 3, in the SDK in general, and in its RPM packaging. As you already did the work to adapt the .spec, would you be so kind so prepare a patch and submit it to gerrit.ovirt.org? Regarding adding the SDK to EPEL (or Fedora) we don't do it because we just don't have enough resources. Do you have Fedora packager permissions? If you do it will be very welcome if you volunteer to add the SDK to both Fedora and EPEL, so that they will be directly available in the distribution.
I never used gerrit, but I can do a pull request on github. I don't have Fedora packager permissions, I'm sorry.
It has to go via gerrit.orvirt.org, github is only a mirror. Using gerrit isn't difficult if you are familiar with git. It is documented here: https://www.ovirt.org/develop/dev-process/working-with-gerrit
Change 77987 is marked as 'Cannot Merge'. But I don't know where is the problem. What can I do to correct that ?
Usually when you see 'Cannot Merge' the problem is that it needs a rebase. There is a 'Rebase' button in gerrit UI. So in most cases it's OK to just hit that button. But you may get error something like "can't rebase, because of conflicts". So in that case you need to rebase the patch on your machine and then push new ammended commit. The problem that it shows the 'Cannot merge' right now, is because there was some patch merged to 'master' branch, so it needs the rebase, because the parent of that patch is outdated.
I think we fix the bug if we publish in the oVirt official repositories RPM packages for CentOS and Python 3.
Closing as wontfix. Fabrice, if you have plans to do otherwise, please re-open.
I'm working on it again.
(In reply to Fabrice Bacchella from comment #13) > I'm working on it again. Any ETA? Anything we can help with this?
In https://gerrit.ovirt.org/#/c/77987/, it says 'Cannot Merge', I don't know why. Should I rebase and try to resubmit it ?
(In reply to Fabrice Bacchella from comment #15) > In https://gerrit.ovirt.org/#/c/77987/, it says 'Cannot Merge', I don't know > why. Should I rebase and try to resubmit it ? Correct - you'll probably need to fix merge conflicts (otherwise it would have allowed to rebase easily).
spec files updated.
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
ok, closing. Please reopen if still relevant/you want to work on it.