[Pulp-dev] To integrate Fus or not to....

[David Davis]

One consideration is that whatever we do for Pulp 2, we’ll have to do again
in Pulp 3. For that reason, as ugly as it is, I am leaning toward calling
to Fus via a pipe. It seems the easiest, least amount of work, and most
reusable.

David


On Wed, Oct 10, 2018 at 10:00 AM Milan Kovacik <mkovacik at redhat.com> wrote:

> ...that might be the question we should ask ourselves once again when it
> comes to recursive copying of units between repositories.
>
> 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:
>
> * 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
>
> * 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].
>
> * 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.
>
> Please let me know what option seems more appealing to you; other option
> suggestion are welcome  too.
>
> Cheers,
> milan
>
> [1] https://github.com/fedora-modularity/fus/pull/46
> [2] https://pulp.plan.io/issues/3528#note-7
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181010/1df673e8/attachment.htm>