<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 5:17 PM Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<br>
<br>
<div class="gmail-m_-9218642592972119672moz-cite-prefix">On 10/12/2018 09:53 AM, Milan Kovacik
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Oct 12, 2018 at 3:59 PM Jeff Ortel
<<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> <br>
<br>
<div class="gmail-m_-9218642592972119672gmail-m_-3485963228516901308moz-cite-prefix">On
10/10/2018 08:59 AM, Milan Kovacik wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>...that might be the question we should ask
ourselves once again when it comes to
recursive copying of units between
repositories.<br>
</div>
<div><br>
</div>
<div>I'd like to poll folks opinions about the
possibilities that we may have when it comes
to integrating third party solvers in Pulp. My
yesterday's chat with the #fedora-modularity
folks about us integrating the Fus[1] solver
in order to reuse the Fus algorithm ran into a
couple of bumps:</div>
<div><br>
</div>
<div>* it would be laborous to create a
programmatic Python API between Fus and Pulp
because we can't directly use the libsolv
thingies (pools, solvables and friends) in
such an API because Fus is written utilizing
GObject, which is incompatible with Swig,
which in turn is used in libsolv to expose the
python bindings. One would have to either
re-wrap libsolv code in Fus to work with
pygobject or submit PRs against libsolv to
support GObject introspection. I dunno the
details of either approach (yet) but from the
sad faces on the IRC and the Fus PR[1] it
seemed like a lot of work but it's still an
option<br>
</div>
<div><br>
</div>
<div>* we still should be able to integrate thru
a pipe into Fus, that would make it possible
to dump modular and ursine metadata into Fus
to perform the dependency solving in a
separate subprocess. We should probably
re-check the reasons behind our previous
decision not to do the same with DNF[2].<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
How is Integration with Fus via pipe (CLI) easier than
with gobject? Either way, you "can't directly use the
libsolv thingies (pools, solvables and friends)".
Right? What am I missing?<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Right, a publish-like operation would be required every
time, for all repositories involved in the copy to dump
the metadata to the pipe(s); sample of this interface is
can be found in Pungi: <a href="https://pagure.io/pungi/blob/master/f/pungi/wrappers/fus.py" target="_blank">https://pagure.io/pungi/blob/master/f/pungi/wrappers/fus.py</a>
the "query" is passed thru command line.<br>
</div>
<div> I just learnt Fedora will keep modules and their
ursine deps in separate repos, so the source repo won't
necessarily be closed on dependencies thus multiple source
repos would be needed.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This be done using the Fus gobject interface as well?<br></div></blockquote><div><br></div><div>we'd just dump the XML (and YAML) metadata and run: fus --repo source1,1,/path/to/pipe1 --repo source2,2,/path/to/pipe2 --repo target,system,/path/to/target_pipe "module(walrus)" "penguin:1-2.3" etc</div><div>then parse the textual output of fus such as:</div><div><br></div><div># ---%>---------<br></div><div> - nothing provides policycoreutils-python-utils needed by container-selinux-2:2.69-3.git452b90d.module_2040+0e96cf1b.noarch <br>Problem 1 / 1:<br> - conflicting requests<br> - nothing provides libpthread.so.0(GLIBC_2.2.5)(64bit) needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides libc.so.6(GLIBC_2.2.5)(64bit) needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides libpthread.so.0(GLIBC_2.3.2)(64bit) needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides /bin/bash needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides /usr/bin/python3 needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides python3-dateutil needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br> - nothing provides dbus needed by atomic-1.22.1-2.module_1637+1872e86a.x86_64<br></div><div># ---->%----------</div><div>(fus:8524): fus-WARNING **: 15:13:09.350: Can't resolve all solvables<br>module:docker:2017.0:20180816194539:3ff668f0.x86_64@f29<br>module:container-tools:2017.0:20180816194450:80bd9113.x86_64@f29<br>*docker-devel-2:1.13.1-61.git9cb56fd.module_2109+7c83ead1.noarch@f29<br>*containers-common-0.1.31-14.dev.gitb0b750d.module_2040+0e96cf1b.x86_64@f29<br><br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"></div><div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>* we should be able to extend current
libsolv solver in Pulp, reimplementing the
algorithm from Fus. This might be as laborous
as the first option. It would probably give us
more flexibility as well as more room for
screwing things up but the responsibility
would be ours alone.<br>
</div>
<div><br>
</div>
<div>Please let me know what option seems more
appealing to you; other option suggestion are
welcome too.<br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>milan</div>
<div><br>
</div>
<div>[1] <a href="https://github.com/fedora-modularity/fus/pull/46" target="_blank">https://github.com/fedora-modularity/fus/pull/46</a></div>
<div>[2] <a href="https://pulp.plan.io/issues/3528#note-7" target="_blank">https://pulp.plan.io/issues/3528#note-7</a><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="gmail-m_-9218642592972119672gmail-m_-3485963228516901308mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Pulp-dev mailing list
<a class="gmail-m_-9218642592972119672gmail-m_-3485963228516901308moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="gmail-m_-9218642592972119672gmail-m_-3485963228516901308moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div></div></div></div>