#3188 Change: RPM 4.20
Closed: Accepted a month ago by zbyszek. Opened 2 months ago by amoloney.

Update RPM to the up coming [https://rpm.org/wiki/Releases/4.20.0
4.20] release.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.


+1

Looking forward to.

FTR I think that handling the removal of %patchN somehow is missing from this change proposal. I asked at https://discussion.fedoraproject.org/t/f41-change-proposal-rpm-4-20-system-wide/109573/3

+1 here, but I also think we should just fix the patch thing... it should be easy enough to script...

I would like to see a concrete plan in the change proposal about how we will handle existing spec files using %patchN.

@ffesti can you confirm this request has been incorporated into the change proposal please?

Thank you!

Yes, it was in the Upgrade/compatibility impact section already. I added it to the Scope section, too.

Don't know if my plan is concrete enough. We still need a provenpackager putting their name down and figure out the details. But it's very clear that we need those packages fixed before pushing the new rpm package and doing them one by one won't cut it. So the need to be done in a mass edit.

I think that myself and @salimma may be able to help here.

RPMLint's next release will include an error for the old %patchN form: https://github.com/rpm-software-management/rpmlint/commit/41b97252a806111e0b435855800aea54952431cf

We can look to backport this if a release isn't ready and then go and ship policy updates to make it fail everywhere.

I think it'd make sense to do a mass replacement soon after the change is approved. We don't need to wait until the rpm release is ready for this.

Metadata Update from @tstellar:
- Issue tagged with: pending announcement

a month ago

I think that myself and @salimma may be able to help here.

RPMLint's next release will include an error for the old %patchN form: https://github.com/rpm-software-management/rpmlint/commit/41b97252a806111e0b435855800aea54952431cf

happy to help, looks like @kevin is a co-maintainer of rpmlint already. The proposal already specifies asking a provenpackager to help fix affected packages so I can help with that part. Presumably we'll leave it up to the maintainer if they want to backport the fix to stable releases as the %patch -N form works on older RPM releases anyway (do we know if it's supported down to epel8?)

Yeah, although I haven't done anything there in a long while and should likely remove myself. ;)

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a month ago

Presumably we'll leave it up to the maintainer if they want to backport the fix to stable releases as the %patch -N form works on older RPM releases anyway (do we know if it's supported down to epel8?)

The %patch -P<n> syntax works all the way back to rpm 3.x and probably even older. The %patch <n>, while technically otherwise preferred, is the much less compatible one. All active Fedora versions support it, but no released RHEL does (although we're hoping to address that for RHEL-9).

So for mass-changing purposes, the -P<n> syntax is the safe choice, and, there's no need to wait for 4.20 to go live for that change, %patchN has already been deprecated for a year so it can be considered a cleanup job.

Login to comment on this ticket.

Metadata