#588 New tag option, allowing repo with all inherited content
Closed: Fixed Opened by ralph.

This request stems from the modularity/MBS folks. Hi!

Today, when repos are generated, their pkglist comes from a call to listTaggedRPMS(...., latest=True, inherit=True). The logic behind this chooses rpms for the repo in a depth-first manner, ordered by:

  • tag inheritance order. the first tag listed is explored first.
  • latest-tagged build wins (for disputes between builds of the same package within the same tag).

We would like to introduce a new tag extras option that instructs make_pkglist to pass latest=False to listTaggedRPMS. This would result in a repo which includes all rpms from all inherited tags. Resolution of which binary rpm will be used by the build would occur at buildtime, determined by dnf/yum.

  • Computation cost. The construction of repos today already takes a long time. For traditional tags with long inheritance chains, and where each tag contains a large body of rpms, producing a repo of all of that content would take a stupendous amount of time. We want to use this tag option only for module builds, which have relatively short inheritance chains, where each tag contains a small body of rpms.
  • Overrides. Traditional buildroot overrides rely on the existing depth-first, tag-order-wins logic. The override tag is specified in such a place that its builds always win over the underlying repo. They wouldn't work as expected in this world. Therefore, traditional tags should not employ this tag option. Modular builds don't expect to use overrides in this way, and so are in the clear.
  • External repos. The way external repos are used today is very particular. Modifying it to work with this extra option would be hairy. There will need to be logic added that somehow disallows combining external repos with this include-all flag.

The only make_pkglist function is in the createdistrepo handler. Are we asking specifically for dist repos to do this?

(I'm guessing this is just a mistaken reference, but if modularity is somehow using dist repos, please indicate)

(I'm guessing this is just a mistaken reference, but if modularity is somehow using dist repos, please indicate)

Your guess is correct. We're just using general tag-repo creation. The createrepo handler is the one we're interested in, and on a second look make_pkglist is indeed not in play there.

@jkaluza found that the more likely place to focus on is https://pagure.io/koji/blob/master/f/hub/kojihub.py#_2319

Commit e8d46e2e fixes this issue

Metadata Update from @julian8628:
- Issue set to the milestone: 1.14

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/588

Please continue any further discussion there.

Metadata