[Pulp-dev] Fwd: Pulp 2 depsolving module errata

[Milan Kovacik]

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/7838f346/attachment.htm>