#4293 Fix (?) do_multilib
Opened by figless. Modified
figless/koji fix_domultilib  into  master

Download 4293.patch

Hello,

We have a need to generate el7 multilib repositories via koji dist-repo.

I couldn't get multilib (koji dist-repo ... --multilib multilib.conf) to work. Looking at the code, the first obvious problem was that the ml_path was incorrect as 'Packages' was not being included in the string.
After fixing this, I was then getting stuck as koji was trying to do a depsolve - which I don't understand why?
In the end I removed most of the logic in the existing do_multilib function and have now managed to have multilib dist-repo generation working for our use-case. That being said, I have no idea if it's "correct".

Is multilib generation still supported?
Does this PR make any sense?

Yep, it is broken. I've created #2539 for that but since no-one complained that it is not working I was quietly assuming that it is really not used anymore.

So, first - why is depsolving needed. You will not get transitive dependencies otherwise. So, you then rely on explicit whitelist in multilib.conf.

Second - there are more issues - your pr assumes i686/x86_64 which is not working for ppc/ppc64, and even not for i386/x86_64, etc.

If it is worth fixing (at least there is some user of this feature :-)) I would fix all of the problems at once. @mikem ?

I know we have folks using dist repos. I don't know the full extent of it.

Originally, dist-repos were intended to be a tool to facilitate faster composes (which is why a lot of the code is the way it is), but I don't think that's been a thing for a long time.

In Brew, we see a few dist-repos getting generated, but not often (and not with multilib). It doesn't look to me like there is any significant use.

In Fedora, they have the tag2distrepo plugin enabled (and oof, that plugin needs an overhaul). It seems that the flatpak plugin relies on it. However, the tag2distrepo plugin always sets multilib=False.

It seems to me that at least some uses of dist-repos are misuses that could be handled with regular repos.

We currently don't have/use any multilib dist-repos (well, clearly since it was broken), but there's a use case where we might want it (making openh264 repos)

It appears that the koji-flatpak plugin relies on dist repos, at least to some extent. @otaylor do you recall why those are desired there instead of normal repos?

It appears that the koji-flatpak plugin relies on dist repos, at least to some extent. @otaylor do you recall why those are desired there instead of normal repos?

IIRC, the reason is that we need the f41-flatpak-app tag to inherit from f41 (so that we inherit the packages from f41), but we need a repository that does not include inherited packages:

$ koji taginfo f41-flatpak-app
Tag: f41-flatpak-app [83545]
Arches: x86_64 aarch64 ppc64le
Groups: appliance-build, build, kiwi-build, livecd-build, livemedia-build, srpm-build
Tag options:
  mock.new_chroot : 1          [f41]
  mock.package_manager : 'dnf5' [f41]
  tag2distrepo.enabled : True
  tag2distrepo.inherit : False
  tag2distrepo.latest : True
Targets that build into this tag:
  f41-flatpak-app (f41-flatpak-app-build, repo#6544359: 2025-01-20 14:51:12.430614+00:00)
  f41-flatpak-runtime-kojira (f41-flatpak-runtime-packages, repo#6544453: 2025-01-21 02:53:07.601056+00:00)
Current repo: no active repo
Inheritance:
  0    ..I. f41 [83496]

cc: @yselkowitz

we need a repository that does not include inherited packages:

That's the same reason why we need dist repos.

Metadata