RPM Support

Ticket moved to GitHub: "pulp/pulp_rpm/2217":https://github.com/pulp/pulp_rpm/issues/2217

History¶

There is currently a 'policy decision' that modules in the base repo (of rhel) don't rely on modular rpms, but that it's not an engineering limitation, and that fedora and rhel will likely do so at some point in the future. This is already a consideration for fedora and fedora-updates repos.

At least in Fedora, you can expect that there will be content in the updates-testing repo depending on content in updates-modular and/or fedora-modular.

This means Pulp will eventually need to support multiple source repos for copy.

Problem¶

As pulp is delivered today, Ursine RPM deps on modular RPMs are NOT covered by test.

Normal, non-modular (ursine) [0] RPMs can depend on module packages.

As an example, the postgres language RPMs depend on the default stream of the postgresql module.

When this is the case, the default module and all artifacts related to that module and the URSINE RPM are ALL copied to the target repo.

At this time, to account for this scenario, a hybrid repo containing URSINE and MODULAR RPMs with modules will be required.

Example¶

Recursive¶

Before¶

• Copy Ursine RPM "zebra-1.0.rpm" from Repo A to B
• Zebra requires modular RPM bar-1.0.rpm and has no other dependencies

default module: module-FOO: [foo-1.0.rpm, bar-1.0.rpm, baz-1.0.rpm]

repo A
  |
  |---- chicken-1.1.rpm
  |---- zebra-1.0.rpm
  |----module-FOO
  |----foo-1.0.rpm
  |----bar-1.0.rpm
  |----baz-1.0.rpm

repo B
  |
  |----bar-0.7.rpm

After Copy¶

Result of copying ursine RPM zebra-1.0.rpm from repo A to repo B:

repo B
 |
 |---- zebra-1.0.rpm
 |----module-FOO
 |----foo-1.0.rpm
 |----bar-1.0.rpm
 |----baz-1.0.rpm
 |----bar-0.7.rpm

All available artifacts are copied, always. There is no way to copy just module on its own,
if any of its artifacts are present in a source repo (repo A).

Solution¶

• Add Ursine RPM permutations that exercise this case for recursive and non_recursive Ursine RPM copies in mixed repos with modular RPMs where default streams are and are not defined.

Note:¶

• the entire module should be treated as a single content unit to the greatest extent possible. it should copy the module that provides both A and B, all if its artifacts, and, the module default
• a module RPM should never be treated as just a normal RPM
• If module has multiple streams, ONLY the artifacts associated with the default module and the default module are copied, correct?
  • only the artifacts associated with the default module stream should ever be considered in the first place. if there is no default stream for a module, then RPMs should not be able to depend on it

References¶

[0] - https://docs.fedoraproject.org/en-US/modularity/architecture/consuming/dnf-behavior/
[1] - https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/features.html?highlight=modularity