See https://rpm-software-management.github.io/mock/Plugin-PackageState for details on adding the necessary mock config.

That won't work well, because there's no distinction between directly required and dependencies. That distinction is quite important when you're trying to cut build dependencies — you need to know what's an actual direct build dependency to cut, and what was dragged in there as a runtime dependency of the build dependency.

We have it in the CentOS Stream koji: https://kojihub.stream.centos.org/kojifiles/packages/autofs/5.1.4/108.el8/data/logs/aarch64/installed_pkgs.log

^^ see it's just one long list of everything.

The root log splits it into two sections: https://kojihub.stream.centos.org/kojifiles/packages/autofs/5.1.4/108.el8/data/logs/aarch64/root.log

1. Installing group/module packages: - directly required
2. Installing dependencies: - dependencies

Content Resolver only takes the directly rquired, and resolves the dependencies itself. If you only use the single list you'll lose the distinction.

Parsing root logs was really the last resort, believe me, I looked at installed_pkgs.log before.

Ideally we'd have arch-specific SRPMs available in a repo. Or actually just the repodata would be enough, we don't need the packages. Just need to have a way to query the dependencies, which are in many cases different per architecture.

In light of that... is this still desired?

It's still desirable for the ELN build sync; We're looking at this as a way to potentially make rebuilds more reliable there by replicating the buildroot more exactly.

It's also desirable to debug sudden build failures. Such lists should be easier to diff.