[Pulp-dev] Pulp 2 depsolving module errata

[Robin Chan]

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 <mkovacik at redhat.com> wrote:

>
> Robin, I think you're right, we should include the folks.
>
> --
> milan
>
> ---------- Forwarded message ---------
> From: Robin Chan <rchan at redhat.com>
> Date: Wed, Dec 5, 2018 at 1:02 AM
> Subject: Re: Pulp 2 depsolving module errata
> To: Milan Kovacik <mkovacik at redhat.com>
> Cc: Daniel Alley <dalley at redhat.com>, Kersom <kersom at 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 <mkovacik at 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 <kersom at 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181205/d1f04e31/attachment.htm>