#588 New tag option, allowing repo with all inherited content
Closed: Fixed 4 years ago Opened 4 years ago 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.

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

4 years ago

Login to comment on this ticket.

Metadata