On 10/10/2018 08:59 AM, Milan Kovacik 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].
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?
* 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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev