[Pulp-dev] Pulp 2 depsolving module errata

[Milan Kovacik]

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 <rchan at 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 <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/de755523/attachment.htm>