<div dir="ltr"><div>I see, yeah, I'm a bit vague; should be like the more detail is specified by by a specific treat requirement, the fewer options should match.</div><div>If there's a unit requiring "module(nodejs)" and there are modules providing multiple streams of the nodejs content in the (source) repository --- "module(nodejs:6), module(nodejs:8)" then Pulp may pick any of the streams.</div><div>If a unit requires particular stream then the stream should be respected by Pulp too. Ditto for the architecture.</div><div><br></div><div>--</div><div>milan<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 2:46 PM Robin Chan <<a href="mailto:rchan@redhat.com">rchan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>I have a question.</div><div>Can you clarify the wording of "that particular module should be copied" in the last 3 bullet use cases? Perhaps a use case? To me same wording implies same behavior - or perhaps I'm not getting the distinction.  Thanks!<br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 3:28 AM Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@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 dir="ltr"><div><br></div><div>Robin, I think you're right, we should include the folks.</div><div><br></div><div>--</div><div>milan</div><div><br></div><div><div><div><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Robin Chan</b> <span dir="ltr"><<a href="mailto:rchan@redhat.com" target="_blank">rchan@redhat.com</a>></span><br>Date: Wed, Dec 5, 2018 at 1:02 AM<br>Subject: Re: Pulp 2 depsolving module errata<br>To: Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>><br>Cc: Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>>, Kersom <<a href="mailto:kersom@redhat.com" target="_blank">kersom@redhat.com</a>><br></div><br><br><div><div dir="auto">Can we continue convo in pull-dev? Feel like these use cases need to live somewhere not email & other may have some input/interest.</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 5:03 PM Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@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 dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Kersom,</div><div><br></div><div>I don't fully understand all the usecases yet but let me try to put some down here:<br><div>* a recursive copy of a module pulls over all module artifacts</div><div>* a recursive copy of a module pulls over all modular dependencies, the other modules this module depends on</div><div>* a recursive copy of an artifact RPM pulls over all units the artifact may depend on<br></div><div>* if a unit depends on a particular module:stream, that particular module should be copied</div><div>* if a unit depends on a particular module:stream:version, that particular module should be copied</div><div>* if a unit depends on a particular module:stream.architecture, then again, that particular module should be copied</div><div><br></div></div><div>Modules behave a bit like repositories --- the consumer is supposed to enable a module and this should make DNF to prefer content from the module over the "ursine" RPMs that provide the same treats or cause a conflict with the modular RPMs (artifacts). To make the situation trickier, an ursine RPM can (afaik) depend on a module (stream) and modules can depend on other modules and the modular RPMs can depend on ursine RPMs. This has some edge-case implications when it comes to the content copy itself:</div><div>* if there is an ursine RPM in a target repository and even if that ursine RPM has a newer version than a modular RPM providing the same treat (such as /bin/sh) and while that module is being copied, the modular (outdated) RPM should be "pulled" together with the module</div><div>* if there are multiple modules with the same name that match the user copy query, every module should be copied (including their dependencies), even though the modules would conflict each other on a consumer system --- one can't enable at the same time multiple streams of the same module</div><div><br></div><div>More specific to Pulp, the modular repositories are expected not to be closed on content dependencies; if this happens, Pulp shouldn't fail but instead, it should copy as many of the dependencies as possible. Pulp should not regress with modules in this regard i(n case we fix <a href="https://pulp.plan.io/issues/4152" target="_blank">https://pulp.plan.io/issues/4152</a>).<br></div><div dir="ltr"><br><div>Further more, we might end up with two algorithms that resolve the dependencies: a conservative one, that tries it's best to avoid unintentional "updates" in the target  repository, such as we introduced in <a href="https://pulp.plan.io/issues/2478" target="_blank">https://pulp.plan.io/issues/2478</a> and another approach, that is more greedy and copies everything that provides particular treat (a content unit might depend on).</div><div><br></div><div>Right now I've been just trying to experiment with the modular dependency solving on top on the Issue #4152 fix <a href="https://github.com/pulp/pulp_rpm/pull/1226" target="_blank">https://github.com/pulp/pulp_rpm/pull/1226</a>, trying to figure out how to express these concerns in the libsolv terms while making sure the the two algorithms in the patch wouldn't break with modular content. I've got some progress but it's still in an early stage: <a href="https://github.com/dparalen/pulp_rpm/commit/43ae38a4ea2a2a843a42cc993e88cd3bf480ee9b" target="_blank">https://github.com/dparalen/pulp_rpm/commit/43ae38a4ea2a2a843a42cc993e88cd3bf480ee9b</a></div><div><br></div><div>Actually, we never groomed the modular depsolving story <a href="https://pulp.plan.io/issues/3740" target="_blank">https://pulp.plan.io/issues/3740</a> so please take the usecases listed here with a grain of salt.</div><div><br></div><div>Cheers,</div><div>milan<br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 9:54 PM Kersom <<a href="mailto:kersom@redhat.com" target="_blank">kersom@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 dir="ltr"><div>Hi Milan,</div><div><br></div><div>If there is any feature/issue related to depsolving that should be tested or that QE should be aware of it, please , file test cases on <a href="http://pulp.plan.io" target="_blank">pulp.plan.io</a>. <br></div><div><br></div><div>Then we will be able to understand the scenarios and clarify doubts with you.</div><div><br></div><div>Regards,</div><div><br></div><div>Kersom<br></div></div>
</blockquote></div>
</blockquote></div></div>
</div></div></div></div></div>
</blockquote></div></div></div>
</blockquote></div>