Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686869 - mock should likely gradually update minimal version of mock-core-configs dependency
Summary: mock should likely gradually update minimal version of mock-core-configs depe...
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-08 15:01 UTC by Jan Pokorný [poki]
Modified: 2019-03-14 19:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-03-14 19:30:33 UTC

Attachments (Terms of Use)

Description Jan Pokorný [poki] 2019-03-08 15:01:05 UTC
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

Thanks for considering.

Comment 1 Jan Pokorný [poki] 2019-03-11 10:32:50 UTC
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?

Comment 2 Jan Pokorný [poki] 2019-03-12 08:46:59 UTC
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:

Comment 3 Miroslav Suchý 2019-03-12 11:53:37 UTC
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.

Comment 4 Jan Pokorný [poki] 2019-03-14 19:30:33 UTC
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:
and I am closing this bug (CANTFIX to mean solution is elsewhere).

Note You need to log in before you can comment on or make changes to this bug.