FTR, the dnf_command, system_dnf_command and dnf_install_command will be fixed "globally" in Mock default configuration by the PR currently being reviewed (see the 2nd commit). But this will land the Mock 4.1 release (waiting till v4.1 is on Koji builders would likely unnecessarily block the DNF team with the change).
FTR, Fedora Copr will be migrated to Mock v4.1 as soon as reasonably possible.

so, in koji we can:

• set mock.package_manager per tag. this sets 'config_opts['package_manager']' in the koji generated mock config.

• we could set per tag env variables

so, I guess we could set those via env variables? or modify koji...

CC: @tkopecek

Hm, so we miss some Koji options?

Strictly speaking, would you mind setting this globally?

config_opts['dnf_command'] = '/usr/bin/dnf-3'
config_opts['system_dnf_command'] = '/usr/bin/dnf-3'
config_opts['dnf_install_command'] = 'install python3-dnf dnf-plugins-core'

It shouldn't cause any harm even if we did this in site-defaults.cfg, I believe.

Oh I misunderstood what you were proposing.

Thats going to break epel7 builds though isn't it? There's no python3-dnf available there (although there is a python2 dnf-plugins-core)

It would be nice to test it in staging first to be 100% sure, but EPEL7 shouldn't be affected.
EPEL7 uses package_manager = yum which implies that yum_command, system_yum_command and yum_install_command are in use.

I'll test in staging tomorrow. If it looks ok, I can try and roll it out to prod.

Hum, so I set this on staging builders.

They correctly seem to use dnf-3 (good!), epel7 continues to use yum and works (good), but I don't seem to see it doing the dnf_install_command? Or is it not logging that anywhere?

For example:

https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=110011447

Am I looking in the wrong place there?

The logging with mock is a mess. In Koji there's some weird config, dunno (I'd suggest having a separate issue for this). I at least see:

Start(bootstrap): installing dnf tooling
Finish(bootstrap): installing dnf tooling

So something is happening there - likely a correct thing if dnf_install_command is in place.
We should dump more info messages there in Mock in the future, at least the PM command we execute :-( I'm trying to solve this, but it isn't easy.

ok, so I guess I will try and push this out then. ;)

Hum... but one thing that occurred to me here. If we push this into koji and dnf5 by default lands in rawhide... won't every maintainer that wants to do local rawhide mock builds have to also add that mock config?

Or do we need to push a new mock package out first that sets this for rawhide?

Or do we need to push a new mock package out first that sets this for rawhide?

Should be good.
Isn't mock 4.1 already in rawhide?

$ dnf repoquery mock --disablerepo='*' --enablerepo=rawhide
mock-0:4.1-1.fc39.noarch

It is... although it's not stable in f37 yet. Would be good to make sure that one is out...

It is... although it's not stable in f37 yet. Would be good to make sure that one is out...

fyi dnf5 is not released on f37. I don't see a problem.

Sure, but f37 users may well want to build things in rawhide chroots. Once dnf5 lands again that would break without the mock changes right?

Anyhow, I'll try and push these changes today....

These changes should be live on all the builders now.

Once dnf5 lands again that would break without the mock changes right?

s/../Without the Koji changes related to Mock configs/ - yes - we need those changes no matter what version of Mock is being used.

This appears to be resolved. I think the DNF team can go ahead and ship the updated DNF/DNF5/LIBDNF packages. Thank you!