Bug 1880769 - mock in F33 has lower version than in F32, breaks upgrade to F33
Summary: mock in F33 has lower version than in F32, breaks upgrade to F33
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Copr Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedFreezeException
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-19 20:23 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2020-12-01 09:40 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-01 09:40:14 UTC
Type: Bug


Attachments (Terms of Use)

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.


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