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 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-OPoc2A5Y3PJBpOiNC10ugx6eCE72K63kz8/edit?usp=sharing),
> 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/MFZHLJA46QM7PVBDB3GRPSQJOI4OZTSX/