From the Anaconda DNF Test Day. Test: take a kickstart whose %packages is just: %packages @core %end install it with DNF, then install it with yum ('inst.nodnf'). The yum install actually crashes at the end due to https://bugzilla.redhat.com/show_bug.cgi?id=1173419 , but you can chroot into the installed system (/mnt/sysimage) to count packages and do whatever else you need to do. When installed with DNF, you get 376 packages. With yum, you get 304. Note, this isn't reproducible with the 'minimal' environment group, because that adds the fedora-release-nonproduct package; when that's included, DNF manages to do the right thing. It's only reproducible with a kickstart that uses @core and doesn't pull in fedora-release-nonproduct. The difference turns out to be fedora-release-server and all its dependencies. fedora-release-server is pulled in by firewalld-config-server. What's going on is that firewalld is in @core, and it requires config(firewalld), which is a virtual provide that all the different firewalld-config-(flavor) packages and firewalld-config-standard provide. yum, using one of its heuristics or other, decides to use firewalld-config-standard to solve the requirement, which is the best choice - it leads to the smallest package set. dnf, which doesn't have yum's heuristics (hence this bug is in part a case of https://bugzilla.redhat.com/show_bug.cgi?id=1181567 ), picks firewalld-config-server , pulling in fedora-release-server, rolekit, yum (ironically enough), a bunch of perl packages, and whatever else. As mentioned this is partly a case of #1181567 - DNF's different handling of ambiguous deps compared to yum - but it could also be considered an issue in the whole mechanism of per-flavor config and release packages, so filing against distribution. sgallagh has suggested just taking firewalld out of @core as a simple workaround. We'd then have the question of whether it should go in @standard, but I suspect a lot more people have kickstarts with @core in than have kickstarts with @standard in.
This is also problem for Docker base image - we don't even have @core in, but it specifies fedora-release directly which leads to the same result of pulling fedora-release-server in and Fedora Rawhide being bloated with unexpected packages.
fedora-release does *not* pull in fedora-release-$PRODUCT. Originally, that was going to be the case, but we discovered it led to circular dependencies. Part of the problem here is that we have both "fedora-release" and "generic-release" packages in the distribution, and the latter has not been properly maintained (so it still includes some old, incorrect pieces, such as the strict dep on system-release-product). I've contacted dgilmore and spot about fixing the generic-release package.
(In reply to Václav Pavlín from comment #1) > This is also problem for Docker base image - we don't even have @core in, > but it specifies fedora-release directly which leads to the same result of > pulling fedora-release-server in and Fedora Rawhide being bloated with > unexpected packages. I discussed this with Dennis Gilmore on Friday. We found that the problem was specifically because the docker base image kickstart includes the directive firewall --disable. In anaconda, this actually causes the firewall-config package to be pulled in, which pulls in firewalld and so on. Omitting this line for the docker base image is both safe and will avoid pulling things in. As for the issue with firewalld in @core, that should be less of a problem once the patches I have on review for BZ #1146487 are pushed. We will no longer be relying on package deps to pull in fedora-release-$edition packages; firewalld and other packages that need per-product differences will simply be able to rely on the contents of /etc/os-release. So if no edition package has been specified, it will just use the default configuration. This will make life much easier.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.