Note, when resolving dependencies, pungi does follow Provides. So if grub2-pc required grub2-common and grub2-common-new provided grub2-common, grub2-common-new would get pulled into the tree. This issue is about the initial list of packages to pull in, that is specified in the variant configuration usually as a list of comps environments, comps groups, and just plain package names.

Last I tried to find out, I was told that comps groups list RPM names, not generic provides.

Pungi in general assumes names in comps are actual package names, not generic Provides both in Yum and DNF backend. The same applies for additional_packages config option.

Resolving dependencies of course has to look at all provides.

I was curious if DNF actually treats names in comps file as not just package name. My simple test case suggests that is not the case.

$ rpm -qp mypkg-1.0-1.noarch.rpm --provides
mypkg = 1.0-1
myprovides = 1.0
$ cat test-comps.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">
<comps>
  <group>
    <id>mygroup</id>
    <name>mygroup</name>
    <description>dummy group</description>
    <default>true</default>
    <uservisible>false</uservisible>
    <packagelist>
      <packagereq type="mandatory">myprovides</packagereq>
    </packagelist>
  </group>
</comps>
$ createrepo_c . --groupfile test-comps.xml
Directory walk started
Directory walk done - 1 packages
Temporary output repo path: ./.repodata/
Preparing sqlite DBs
Pool started (with 5 workers)
Pool finished
$ sudo dnf  --repofrompath=myrepo,$(pwd) --repo=myrepo group install mygroup
Added myrepo repo from /home/lsedlar/repos/pungi/noarch
myrepo                             1.0 MB/s | 1.0 kB     00:00    
Last metadata expiration check: 0:00:00 ago on Tue Sep  5 10:56:14 2017.
No match for group package "myprovides"
Dependencies resolved.
==================================================
 Group                                    Packages
==================================================
Marking packages as installed by the group:
 @mygroup
Is this ok [y/N]: N
Operation aborted.

Well, the example I chose was a 'real life' one. @pjones really did remove the package called grub2 and replace it with packages named more or less by arch: grub2-pc on i686 and x86_64, grub2-ppc64 on ppc64, grub2-ppc64le on ppc64le. So if we can't just list grub2 in comps, meaning 'pull in whatever the hell provides grub2 on this arch', we have to list all the possibilities:

grub2-pc
grub2-ppc64
grub2-ppc64le

and then we have to ensure that dnf continues skipping 'missing' packages without error (which is something that's bitten us before). Or we have to explicitly list the correct package name by arch, which is a fairly new feature in comps we have never actually tried using before. And in both cases we're now kinda encoding package details that @pjones might change again, whereas the idea that something is going to provide grub2 is probably a safer long-term assumption. So, that's kinda why I figured this was worth bringing up as a bug.

As for the question about what treats the things in comps as Provides and what treats them as literal package names...I think I was inferring that based on how various artifacts of the compose process turned out, but I forget the details now. I'm pretty sure some things that worked should have failed if dnf didn't follow Provides. But your test looks valid, so I'm not 100% sure what's going on there.

Basically this is all a pool of undefined behaviour and expectations, joy :/