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

[Milan Kovacik]

...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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181010/ef61819d/attachment.htm>