[Pulp-dev] Pulp RPM dependency solver refactoring dilemma
mkovacik at redhat.com
Wed Jun 27 10:11:38 UTC 2018
On Tue, Jun 26, 2018 at 8:04 PM, Justin Sherrill <jsherril at redhat.com>
> On 06/26/2018 11:30 AM, Milan Kovacik wrote:
>> TL;DR should we support alternative solvers (configuration) during
>> recursive unit association?
>> I've been refactoring the current approach to RPM dependency solving
>> for e.g the recursive copy to be able to handle rich dependencies.
>> While testing, I ran into an dependency issue that is caused by me not
>> processing file-provides records correctly.
>> No matter the current insufficiency in my coding, a user trying to
>> copy stuff from a repo with libsolv-unresolvable dependencies might
>> hit similar issues and consider them regressions from previous
>> behavior, hence the question:
>> Should the user be able to select a solver (configuration) for
>> particular associate call thru the REST API?
> I commented on the PR, but i think the behavior we're seeing is okay and
> can be ignored (assuming we can still pull in the deps that are
> available). Assuming we can, do we still need it to be configurable?
Turns out we can by simply ignoring the solver problems; might have as well
investigated it yesterday ;)
> I would also like to point out this issue to keep in mind:
That behaviour is already addressed in the PR by the solver considering the
target repository content
I wonder whether I should set the issue state accordingly...
>>  https://github.com/pulp/pulp_rpm/pull/1122
>>  https://github.com/pulp/pulp_rpm/pull/1122#issuecomment-400061802
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev