<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 4:56 PM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 16, 2016 at 9:35 AM, Yaniv Bronheim <<a href="mailto:ybronhei@redhat.com">ybronhei@redhat.com</a>> wrote:<br>
> Hi<br>
><br>
> After merging<br>
> <a href="https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:cross-imports" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/q/<wbr>status:open+project:vdsm+<wbr>branch:master+topic:cross-<wbr>imports</a><br>
<br>
</span>This is not related to this patch, we had to keep correct spec,<br>
automation and dockerfile<br>
before this patch. This patch keeps us honest, preventing wrong code<br>
from sneaking in.<br></blockquote><div>yes.. but now we see how annoying it is :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the first run, it found that python-requests was missing (fixed now)<br>
and that vdsm.rpc modules are doing wrong import from /usr/share/vdsm.<br>
These imports work by accident. This was not discovered in the review<br>
of the patch moving rpc to lib/vdsm.<br>
<br>
This patch is fixing the old crossImports check that was totally broken,<br>
checking imports is not a new concept, it simply works now.<br>
<span class=""><br>
> we need now for any new requirement to add a line in:<br>
> check-patch.packages.el7<br>
> check-patch.packages.fc24<br>
> check-merged.packages.el7<br>
> check-merged.packages.fc24<br>
<br>
</span>You forgot build-artifacts.packages.* - total of 6 files to update in<br>
automation/<br>
<br>
I suggested David Caro in the past to support reading multiple packages files,<br>
so you can have a check-patch.packages file, *and* check-patch.packages.el7<br>
and the ci will merge the list of packages, so you don't have to duplicate the<br>
packages 6 times in every project.<br>
<span class=""><br></span></blockquote><div><br></div><div>they can use the spec as well with builddep. don't see any problem with that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> <a href="http://vdsm.spec.in" rel="noreferrer" target="_blank">vdsm.spec.in</a><br>
> Dockerfile.centos<br>
> Dockerfile.fedora<br>
><br>
> seems like we can add it once to the spec with section for fedora and centos<br>
> and the rest of the places will use yum-builddep. sounds more reasonable to<br>
> me and probably the right way to work with rpms dependencies. no?<br>
<br>
</span>The issue is we have different kind of requirements:<br>
- runtime packages<br>
- runtime packages needed during tests (smaller set, since not all<br>
code is tested)<br>
- build packages (needed only for building rpms)<br>
- check-merged packages (lago and friends?)<br>
<br></blockquote><div>with you check we require everything we import even if we don't have test for that. so basically now all of the above requires the same list</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So we can use the spec as the source, and generate all the other files<br>
during make, but this means the spec and all the *packages files will<br></blockquote><div> </div><div>why generating? what's wrong with rpm commands to install deps?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
include all the packages for the worst case, making the build even slower.<br></blockquote><div><br></div><div>can you give an example of such package that we don't need in check-patch and built-artifacts but we need in runtime? we should test all :) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But note that the dockerfiles must be correct regardless where you build<br>
vdsm - you have to get different list of packages for fedora and centos<br></blockquote><div> </div><div>you can do that in the spec as well </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so you can build the docker image on any system. I'm not sure keeping<br>
stuff in the spec will make it easy to extract for crating other files, keeping<br>
the files in a json / yaml file and generating the spec during configure may<br>
be easier.<br>
<br>
I think it worth the effort if we avoid updating 9 files when adding<br>
requirements.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nir<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px"><b>Yaniv Bronhaim.</b></span><br></div></div></div></div></div>
</div></div>