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. 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. If a unit requires particular stream then the stream should be respected by Pulp too. Ditto for the architecture.
-- milan On Wed, Dec 5, 2018 at 2:46 PM Robin Chan <rc...@redhat.com> wrote: > I have a question. > 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! > > > On Wed, Dec 5, 2018 at 3:28 AM Milan Kovacik <mkova...@redhat.com> wrote: > >> >> Robin, I think you're right, we should include the folks. >> >> -- >> milan >> >> ---------- Forwarded message --------- >> From: Robin Chan <rc...@redhat.com> >> Date: Wed, Dec 5, 2018 at 1:02 AM >> Subject: Re: Pulp 2 depsolving module errata >> To: Milan Kovacik <mkova...@redhat.com> >> Cc: Daniel Alley <dal...@redhat.com>, Kersom <ker...@redhat.com> >> >> >> Can we continue convo in pull-dev? Feel like these use cases need to live >> somewhere not email & other may have some input/interest. >> >> On Tue, Dec 4, 2018 at 5:03 PM Milan Kovacik <mkova...@redhat.com> wrote: >> >>> Hi Kersom, >>> >>> I don't fully understand all the usecases yet but let me try to put some >>> down here: >>> * a recursive copy of a module pulls over all module artifacts >>> * a recursive copy of a module pulls over all modular dependencies, the >>> other modules this module depends on >>> * a recursive copy of an artifact RPM pulls over all units the artifact >>> may depend on >>> * if a unit depends on a particular module:stream, that particular >>> module should be copied >>> * if a unit depends on a particular module:stream:version, that >>> particular module should be copied >>> * if a unit depends on a particular module:stream.architecture, then >>> again, that particular module should be copied >>> >>> 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: >>> * 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 >>> * 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 >>> >>> 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 >>> https://pulp.plan.io/issues/4152). >>> >>> 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 >>> https://pulp.plan.io/issues/2478 and another approach, that is more >>> greedy and copies everything that provides particular treat (a content unit >>> might depend on). >>> >>> Right now I've been just trying to experiment with the modular >>> dependency solving on top on the Issue #4152 fix >>> https://github.com/pulp/pulp_rpm/pull/1226, 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: >>> https://github.com/dparalen/pulp_rpm/commit/43ae38a4ea2a2a843a42cc993e88cd3bf480ee9b >>> >>> Actually, we never groomed the modular depsolving story >>> https://pulp.plan.io/issues/3740 so please take the usecases listed >>> here with a grain of salt. >>> >>> Cheers, >>> milan >>> >>> On Tue, Dec 4, 2018 at 9:54 PM Kersom <ker...@redhat.com> wrote: >>> >>>> Hi Milan, >>>> >>>> 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 >>>> pulp.plan.io. >>>> >>>> Then we will be able to understand the scenarios and clarify doubts >>>> with you. >>>> >>>> Regards, >>>> >>>> Kersom >>>> >>>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev