On Thu, Feb 28, 2019 at 1:30 PM Dan Kenigsberg <[email protected]> wrote:
> On Thu, Feb 28, 2019 at 1:07 PM Marcin Sobczyk <[email protected]> > 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-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 -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected]/message/MFZHLJA46QM7PVBDB3GRPSQJOI4OZTSX/ >
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/XTCNER2YAGH4EU5LEE322IRZSP4IDU3Y/
