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
