DescriptionAdam Williamson
2018-02-19 21:42:05 UTC
Current Fedora Rawhide installer image composes are rather broken because they contain fedora-modular-release and fedora-modular-repos , not fedora-release and fedora-repos . This causes them to try and use a non-existent repository and fail to be able to set up packaging at all.
This changed between Fedora-Rawhide-20180212.n.0 and Fedora-Rawhide-20180213.n.0 (though we didn't notice till today as both those composes, and all between 20180204.n.0 and 20180218.n.0, ultimately failed entirely for other reasons).
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180212.n.0/logs/x86_64/buildinstall-Everything.x86_64.loghttps://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180213.n.0/logs/x86_64/buildinstall-Everything.x86_64.log
Those are the 'Everything' buildinstall logs for the two composes in question (the logs for other variants are similar). Note that in 20180212.n.0 'fedora-release', 'fedora-repos' and 'fedora-repos-rawhide' are installed, but in 20180213.n.0, 'fedora-modular-release' and 'fedora-modular-repos' are installed (there is no 'fedora-modular-repos-rawhide').
I made a diff of all the packages between those two composes. There are quite a lot as it was in the middle of the mass rebuild, but one obvious suspect leaps out: dnf-2.7.5-8.fc28 . The changelog for that build says:
* Mon Feb 12 2018 Daniel Mach <dmach> - 2.7.5-8
- Rebase to dnf from dnf-2-modularity branch.
so this certainly looks like it could be the cause.
I *suspect* that ultimately nothing in the package set pulled in by lorax during these image composes specifically requires fedora-release; instead there is at least one package (setup - there may be others too) that requires system-release. system-release is provided by fedora-release, fedora-modular-release and generic-release, so we're relying on dnf to pick 'the right one' there, somehow. I think something in the 'dnf-2-modularity' branch causes it to prefer fedora-modular-release to satisfy that requirement where previously it preferred fedora-release. That is only my suspicion, though, there may be some other explanation.
Proposing as a Fedora 28 Beta blocker, as a violation of "...Release-blocking network install images must default to a valid publicly-accessible package source." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_package_sources . This is violated for the Everything network install image, which does not do that any more.
The fedora-modular-release was probably picked by depsolver.
You need to specify fedora-release manually if you want to include it as a priority package.
I don't think this is a bug.
Well, it's not entirely that simple, but in any case, we solved this a different way: the package has been retired. I've verified that recent composes are back to using fedora-release and fedora-repos.