+1

+1

Looking forward to.

+1

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...

+1

+1

+1

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.

Plug for https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes for this process. ;)

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.

APPROVED (7, 0, 0)

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. ;)

Announced.

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.