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
