2:39 p.m.
Hi,
I've posted a series of patches:
https://gerrit.ovirt.org/#/q/topic:py3-rpm-packages+(status:open+OR+statu...
They do a couple of things:
* add an '--enable-python3-build' argument to 'autogen.sh'
* modify 'Makefile.am' so it uses either 'vdsm.spec.in' or
'vdsm-py3.spec.in' file to build RPMs
* preserve the 'vdsm.spec[.in]' filename in dist archives for both py2
and py3 packaging
* fix shebang lines in a dist-hook, so that py3 packages will contain
only '#!/usr/bin/python3' shebangs
* prepare the CI for building py3 packages on fc28
So actually, if we replace the dummy 'vdsm-py3.spec.in' file in
https://gerrit.ovirt.org/#/c/98119/ with something useful (be it the
nasty, hacky one, or the shiny, new one), we're ready to build py3 packages.
Reviews are more than welcome.
Regards, Marcin
On 2/28/19 2:02 PM, Milan Zamazal wrote:
Marcin Sobczyk <msobczyk(a)redhat.com> writes:
> Hi,
>
> On yesterday's vdsm weekly call, we were discussing the need of making
> Python 3 vdsm RPM packages.
>
> Some facts:
>
> - it doesn't make a lot sense to spend much time on trying to package
> everything - it's completely impossible i.e. to run vdsm without
> having 'sanlock' module
> - our current vdsm.spec file is crap
>
> Two non-exclusive propositions were raised:
>
> - let's try to make a quick-and-dirty patch, that will completely
> overwrite the existing 'vdsm.spec' (effectively making it Python
> 3-only) for testing purposes, and maintain it for a while
> - in the meantime, let's write a completely new, clean and beautiful
> spec file in an package-by-package, incremental manner, (also Python
> 3-only) that would eventually substitute the original one
>
> The quick-and-dirty spec file would be completely unsupported by
> CI. The new one would get a proper CI sub-stage in 'build-artifacts'
> stage.
>
> The steps needed to be done are:
>
> - prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds
> - prepare the new spec file (for now including only 'vdsm-common' package)
> - split 'build-artifacts' stage into 'build-py27' and
'build-py36'
> sub-stages (the latter currently running on fc28 only)
And solve #/usr/bin/python* issue.
> The only package we can start with, when making the new spec file, is
> 'vdsm-common', as it doesn't depend on anything else (or at least I
> hope so...).
>
> There were also propositions about how to change the new spec file in
> regard to the old one (like making 'vdsm' package a
> meta-package). This is a good time for these propositions to be
> raised, reviewed and documented (something like this maybe?
>
https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72...),
> so we can align the new spec file as we build it.
>
> I can lay the groundwork by doing the autotools/Makefiles and
> 'build-artifacts' splitting. Gal Zaidman agreed on starting to work on
> the new spec file. Milan mentioned, that he had something like the
> quick-and-dirty patch, maybe he can share it with us.
I can try to post a patch with a q&d Python 3 vdsm.spec.in file; maybe
later today.
> Questions, comments are welcome.
>
> Regards, Marcin