On Thu, Feb 28, 2019 at 1:30 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Feb 28, 2019 at 1:07 PM Marcin Sobczyk <msobczyk@redhat.com> wrote:
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
I'm not sure I understand that second option. I am afraid of fresh starts; I'd very much prefer to start from the sh*tty thing we have, and evolve it. A lot of time, re-writing a piece of software is tempting, but existing code is imbued with knowledge of past problems, which is often forgotten when you do a hard cut.
True, but if you pick a small enough component, replacing bad component with good one is much quicker. Cleaning %files should be an easy first step; This is a good idea anyway.
I think that Gal's jinja-based generation of py2/py3 packages is sane. Can you explain why not just to carry these patches over?
Adding jinna to the mix will only make the spec harder to work with, we will have spec + shell + jinna + autoconf in the same file. And when we delete the python 2 support we will have to live with that complexity that serve nothing. We need now: - python 2 for rhel 7 - python 2 for fedora - python 3 for rhel 8 - python 3 for fedora Once we have working python 3 versions, we can drop the python 2 builds, so we will have a single spec with: - pyhton 3 for rhel 8 - pyhton 3 for fedora So investing time and energy on having "smart" spec that support both python 2 and 3 is waste of effort. Idealy the new spec will be static, no code generation, no code. All code (e.g. install/upgrade scripts) should be in separate files that can be tested easily.
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)
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-OPoc2A5Y3PJBpOiNC10ugx6eCE72K63... ),
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.
Questions, comments are welcome.
Regards, Marcin
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/MFZHLJA46QM7PV...