5:42 a.m.
On 2/28/19 12:30 PM, Dan Kenigsberg wrote:
On Thu, Feb 28, 2019 at 1:07 PM Marcin Sobczyk
<msobczyk(a)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.
Cleaning %files should be an easy first step; 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?
AFAIK, 4.4 will be
RHEL8-only. This means, we will drop Python 2 completely.
Trying to make the existing spec file work with both Python 2 and Python
3 is a wasted effort.
It also complicates things a lot (new build dependency, 2 layers of
preprocessing) unnecessarily.
I'm pretty confident, that introducing the new spec file package by
package, will work for us - it's not Python code, errors will probably
emerge quickly.
+, we would still have the original spec, until we're done, to have a
reference point.
>
>> 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-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.
>>
>> Questions, comments are welcome.
>>
>> Regards, Marcin
>>
>> _______________________________________________
>> 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/MFZHLJA46QM...