#1307 source_repos: hardcoded value?
Opened 4 years ago by fepitre. Modified 4 years ago

Hi,
Looking at https://pagure.io/pungi/blob/master/f/pungi/phases/pkgset/sources/source_repos.py#_83, there is several hardcoded values like 'fulltree=True'. It has the consequence to dump all a remote repo when doing a compose. Is is a wanted behavior?


Yes, this is wanted and expected. The packages downloaded by the pkgset source are not the final output of the compose. They merely populate a local repo, which is then fed to a dependency solver to figure out the final list of packages.

So finally we are far from pungi(legacy) behavior to simply ask/download to/from the repo what is needed?

We (QubesOS) are looking for a workaround to this and we are thinking of three solutions:
1) Patch Pungi to not setting it to True for only resolving Fedora's repos what's needed but maybe we are going to face other problems?
2) Before calling pungi-koji, gather only needed package to a local repo and then adding it as a repo for the compose. Disadvantage is duplicating locally the repo.
3) Rewrite pungi-legacy with python3?

As we want as maximum as possible to merge efforts with upstream, any idea of what would be the best for our both communities?

Just to confirm - does Fedora compose process really involve downloading all the ~55000 Fedora packages consisting of several tens of GBs, just to produce ISO image(s) with a fraction of them? Or maybe I don't understand something in this process?

Just to confirm - does Fedora compose process really involve downloading all the ~55000 Fedora packages consisting of several tens of GBs, just to produce ISO image(s) with a fraction of them?

No, it doesn't. The package source is not repos, but Koji. Pungi has access to the volume and can copy needed packages from there (and it does not need all of them).

The repos are actually the main output of the compose process.

1) Patch Pungi to not setting it to True for only resolving Fedora's repos what's needed but maybe we are going to face other problems?

With this you are possible have missing packages.

2) Before calling pungi-koji, gather only needed package to a local repo and then adding it as a repo for the compose. Disadvantage is duplicating locally the repo.

The problem here is that pungi-gather is what figures out which packages are needed.

A better approach might be to change the repos package set source to not copy the repos locally (which is done by calling pungi-gather with the options that make it download every single package), and instead use the repos directly for depsolving (which is another invocation of pungi-gather with more sensible options).

A relatively easy way to achieve this might by mirroring the repo locally with mergerepo_c and then updating the code in gather phase that hardlinks RPMs to be able to download the needed packages (probably by using --download argument for pungi-gather).

3) Rewrite pungi-legacy with python3?

This would require porting from Yum to DNF, it's not a small task. If you decide to do this, I would recommend considering doing it in a new project/repo to have more freedom.

1) Patch Pungi to not setting it to True for only resolving Fedora's repos what's needed but maybe we are going to face other problems?

With this you are possible have missing packages.

2) Before calling pungi-koji, gather only needed package to a local repo and then adding it as a repo for the compose. Disadvantage is duplicating locally the repo.

The problem here is that pungi-gather is what figures out which packages are needed.
A better approach might be to change the repos package set source to not copy the repos locally (which is done by calling pungi-gather with the options that make it download every single package), and instead use the repos directly for depsolving (which is another invocation of pungi-gather with more sensible options).

I would say we could go with this solution if it's something you would validate as upstream?

A relatively easy way to achieve this might by mirroring the repo locally with mergerepo_c and then updating the code in gather phase that hardlinks RPMs to be able to download the needed packages (probably by using --download argument for pungi-gather).

3) Rewrite pungi-legacy with python3?

This would require porting from Yum to DNF, it's not a small task. If you decide to do this, I would recommend considering doing it in a new project/repo to have more freedom.

From upstream point of view I'm ok with such change.

Login to comment on this ticket.

Metadata