Learn more about these different git repos.
Other Git URLs
When dnf, or anything built on it, takes a 'package name' - say, from a comps group - and tries to install it, it will follow Provides. For instance, if a comps group anaconda-tools lists grub2, and a package called grub2-pc provides grub2, then running dnf install @anaconda-tools will cause the package grub2-pc to be installed.
dnf install @anaconda-tools
When populating the variant trees with package files, Pungi does not do this. It's quite hard to follow Pungi's source, but if I got it right, I believe this ultimately comes down to the Pungi.getPackageObjects() method, which (still) uses yum.packages.parsePackages to turn a list of package names (which came in through all the gather sources / methods stuff) into a list of package objects. Again if I read it right, parsePackages does not consider Provides, it really only finds packages with the exact name (or matching a name glob, but it doesn't follow Provides).
Note, 'fixing' this may be a somewhat disruptive change, as it could possibly cause unexpected consequences for established comps files (etc.) that have been built on the old behaviour for a long time. But it seems to be an inconsistency between pungi and dnf in handling the exact same information source.
A larger question here is why Pungi painfully reinvents comps parsing on its own instead of just sharing the code with dnf...
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">
$ 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)
$ 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"
Marking packages as installed by the group:
Is this ok [y/N]: N
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:
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 :/
Metadata Update from @lsedlar:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)
to comment on this ticket.