Bug 1880769

Summary:	mock in F33 has lower version than in F32, breaks upgrade to F33
Product:	[Fedora] Fedora	Reporter:	Zbigniew Jędrzejewski-Szmek <zbyszek>
Component:	mock	Assignee:	Copr Team <copr-team>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	awilliam, copr-team, jkeating, mebrown, msuchy, philip.wyett, praiskup, williams, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	RejectedFreezeException
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-12-01 09:40:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Zbigniew Jędrzejewski-Szmek 2020-09-19 20:23:48 UTC

Description of problem:
Release	Stable version	Version in testing
Fedora 34	mock-2.6-1.fc34	
Fedora 33	mock-2.4-1.fc33	mock-2.6-1.fc33
Fedora 32	mock-2.5-2.fc32	mock-2.6-1.fc32

Comment 1 Fedora Blocker Bugs Application 2020-09-19 20:25:17 UTC

Proposed as a Freeze Exception for 33-beta by Fedora user zbyszek using the blocker tracking app because:

 Upgrade from F32 is broken because the version in f33-updates is lower.

Comment 2 Pavel Raiskup 2020-09-20 06:14:04 UTC

I pushed the F33 update to stable then, but ...

Fedora N+1 no longer needs to have higher NVRs.  I though can not find
an explicit statement in guidelines claiming so, I only found:
https://fedoraproject.org/wiki/Taskotron/Tasks/dist.upgradepath

As such, I don't think this bug can be qualified as blocker.

Comment 3 Zbigniew Jędrzejewski-Szmek 2020-09-20 08:31:15 UTC

I should have been more explicit: I filed the bug only to submit it for a freeze exception (not blocker).

> Fedora N+1 no longer needs to have higher NVRs.

Hmm, yeah, I can't find *any* statement about this anywhere.
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ says
> an upgrade path check (to ensure the update does not break the upgrade path from release to release,
> i.e. that the update does not contain a package versioned higher than the newest version of the same
> package available in a later Fedora release).

But of course that's not policy, that's a description of a non-existent check system.
I filed https://pagure.io/fesco/issue/2473 to discuss this.

Nevertheless, even if the policy does not require it, in this particular case, I think it's not nice
to downgrade users from 2.5 to 2.4, so I think we should push the mock update to beta if possible.

Comment 4 Fedora Update System 2020-09-20 11:25:29 UTC

FEDORA-2020-8b8b3ade7b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b8b3ade7b

Comment 5 Adam Williamson 2020-09-21 19:12:53 UTC

zbyszek: all the 'approved' upgrade methods now effectively do 'distro-sync', so they will downgrade packages in situations like this. Thus it is less important than before to keep the upgrade path in line, though obviously still a good idea.

Comment 6 Adam Williamson 2020-09-21 19:13:36 UTC

Discussed at 2020-09-21 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-09-21/f33-blocker-review.2020-09-21-16.00.html . Rejected as a freeze exception issue as it doesn't actually break approved upgrade methods, and the new version can go out as a 0-day update without really causing any problems.

Comment 7 Fedora Update System 2020-09-25 16:43:58 UTC

FEDORA-2020-8b8b3ade7b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.