Story #3847

Updated by milan over 4 years ago

 Pulp lacks resolving of "RPM weak forward dependency": @Recommends@ during content association in case of e.g recursively copying RPMs between repositories, which by default is respected by @dnf@ A content gap might therefore be induced on a consumer machine when installing from a repository containing just the recursive-copy calculated dependencies of an RPM unit. This isn't a breaking discrepancy as "by definition, weak dependencies missing don't cause an unit to break": 

 The very weak/hint @Suggests@ field is out of scope "as hints are by default not processed by @dnf@": 
 Bot the weak and very weak/hint backward fields: @Supplements@ and @Enhances@ are out of scope too. 

 Publishing the weak dependencies in repository metadata is out of scope of this story as this is already supported trivially. story focuses on RPM importer association code path with regards to the "recursive usecase". 

 h3. Implementation 

 * the "RPM model":,#L772 needs to track the following "forward" weak dependency field    @Recommends@ 
 * the "primary XML repo metadata parsing code": has to be updated in order to populate the @Recommends@ field 

 h3. Examples 

 I've found few @Recommends@ field samples in the Fedora28--Workstation flavor "primary.xml": repodata file. The @dnf@ unit recommends installing these two items, with rich dependency conditioning: 

 <pre><code class="xml"> 
   <rpm:entry name="(/usr/bin/sqlite3 if bash-completion)"/> 
   <rpm:entry name="(python3-dbus if NetworkManager)"/> 

 h3. Notes 
 * the RPM content upload code needn't be updated as it "reuses the XML parsing code":,#L384 
 * the backwards dependencies needn't be processed because the Pulp workflow is closer to a repo closure calculation than to an actual content installation 
 * the processing of the @Recommends@ field is going to be "handled thru @libsolv@": once that PR lands 
 * weak dependencies processing can be "switched off": in @dnf@; see also: @man dnf.conf@ 
 * very weak dependencies/hints are most likely just completely ignored by @dnf@