[ovirt-devel] Re: Building python 2 and python 3 packages for Fedora
On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
In several projects (e.g. vdsm, imageio, sanlock), we have the issue of building python 3
packages
for Fedora.
The current build process create packages with the same name for both python 2 and python
3.
When the packages are published to oVirt repository, the python 3 packages overwrite the
python 2
packages.
We can rename the packages properly (e.g. python2-xxx, python3-xxx) but this requires lot
of work
and typically breaks later in the code publishing the packages.
There is also the difficulty of building both python 2 and python 3 packages from same
spec in the same
build. This should be possible but not easy.
I agree about both, but we already have several projects that do
exactly that, so we do have some experience.
Since python 2 is about to die soon, should we simplify by building python 2 *or* python
3, depending
on version?
Fedora 29: python 2.7
Fedora 30: python 3.7
CentOS 7: python 2.7
CentOS 8: python 3.6
Generally speaking, this is the approach we took with stand-alone
tools, e.g. ovirt-iso-uploader, ovirt-engine*setup*.
With libraries, we did package for both - e.g. otopi (not a pure
library, but not a standalone tool either), ovirt-engine-lib.
This make it possible to test and develop on python 2.7 until vdsm is fully functional on
python 3,
and it save resources in the CI.
vdsm is similar to the (python code in the) engine, in that regard.
Most of it is a set of standalone tools, but some parts are libraries,
also used by external tools.
If you package the libraries for only a single version of python, you
require all the 3rd-party tools to adapt their python support exactly
at same cadence of vdsm. By providing libraries for both, at least for
some time, you allow a smoother transition. If you want to avoid that,
I guess it's best to enumerate the current users of vdsm library code,
and coordinate with these. This includes hosted-engine*, but perhaps
also others, not sure.
Best regards,
Thoughts?
Nir
_______________________________________________
Devel mailing list -- devel(a)ovirt.org
To unsubscribe send an email to devel-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FVA4ACELS4H...
--
Didi