Scenario from practice: 0. f30 branched -> 1. unable to build with mock for Rawhide/F30 for "GPG check failed" -> 2. dnf update mock -> 3. same outcome as in 1. -> 4. dnf update mock-core-configs -> 5. mock will start working for Rawhide/F30 Ideal scenario: 0. -> 1. -> 2. -> 5. For that to happen, it seems that mock would need to keep up with the surrounding pace and bump the version for its mock-core-configs dependency. Thanks for considering.
On a second thought, I can imagine the separation of the two packages was very intentional, but can at least mock detect its own failures which may be resolved with updating mock-core-configs (like when GPG signature checks will stop working in the chrooted build environment as I encoutered) and suggest doing so to the user?
Perhaps all that's needed (catch-all style) is to make changes to dnf and possibly also to repo metadata (or generally to release procedures) for modified dnf to use so that the switch to a new key is _always_ a breeze, yet without compromising security in any way (which is currently an easiest workaround, sadly), see also this fedora-devel thread in which I detailed also a current brokenness of trying to install anything with the current fedora:rawhide Docker Hub image, which has the same underlying cause: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MFX2JDVANNEW7LWWIBBLYCN6DEPWHSXF/
Note that this is an issue only for rawhide. The problem is that the name of the file does not change, but the content change (during branching). And it is date driven change. Catching that from code - and without internet access is IMHO impossible. The other option is to release mock together with new mock-core-configs and enforce the latest version. I am not sure I want this. IMHO if you are running rawhide or building for rawhide then 'dnf upgrade' after branching is a must.
re [comment 3]: > IMHO if you are running rawhide or building for rawhide then 'dnf > upgrade' after branching is a must I see, and the trigger to know branching occurred could be something that can be deduced from repo metadata (even if only when extended first) -- that' what I anticipated with > possibly also to repo metadata Having no internet access had nothing to do with my workflows where I have been bitten regadless, not sure if that shall be a strong deciding factor on the path forward. Anyway, best of all is to solve in at the outermost level, I figure, so thank you for response here and especially to that broader topic: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TD2Z4RQHWTHNYN7VCEHXPBAFPWRDA7CF/ and I am closing this bug (CANTFIX to mean solution is elsewhere).