F41 Change Proposal: RPM 4.20 (System-Wide)

[system]

RPM 4.20

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

Summary

Update RPM to the up coming 4.20 release.

Owner

• Name: Florian Festi
• Email: ffesti@redhat.com

Detailed Description

RPM 4.20 contains various improvements over previous versions.

• Hands-free packaging
  • Declarative build system
  • Dynamic spec generation extended
  • File trigger scriptlet arguments
  • Support for spec local dependency generators
  • Support for sysusers ‘m’ directive
  • Guaranteed per-build directory
• Public plugin API
• Increased install scriptlet isolation (#2632, #2665)

The 4.20 alpha release is expected in late March/early April and the final release is expected in time for the Fedora 41 release cycle as usual.

Feedback

Benefit to Fedora

This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above.

Scope

• Proposal owners:

  • Release RPM 4.20 alpha
  • Rebase RPM in rawhide
  • Assist with dealing with incompatibilities

• Other developers:

  • Test new release, report issues and bugs

• Release engineering: #Releng issue number

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Community Initiatives: None

Upgrade/compatibility impact

How To Test

Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation.

User Experience

There are no major differences in the normal user experience.

Dependencies

Contingency Plan

• Contingency mechanism: Revert back to RPM 4.19
• Contingency deadline: Beta freeze
• Blocks release? No

Documentation

Release notes at rpm.org - Releases (still tbd) and reference manual at rpm.org - RPM Reference Manual

Last edited by @mattdm 2024-04-04T22:12:23Z

[amoloney (Aoife Moloney)]

This change proposal has now been submitted to FESCo with ticket #3188 for voting.

To find out more, please visit our Changes Policy documentation.

[churchyard (Miro Hrončok)]

Assuming this indeed removes the support for %patchN as was planned, is there a plan to mass fix our packages or let them FTBFS?

Currently, 1061 rawhide spec files use that.

[system]

How do you feel about the proposal as written?

• Strongly in favor
• In favor, with reservations
• Neutral
• Opposed, but could be convinced
• Strongly opposed

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

[mattdm (Matthew Miller)]

Alignment with Community Initiatives: None

Not yet an initiatve, but I think that declarative build system support and spec local dep generators (at least) fall under Objective Review: We integrate programming language stack ecosystems

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

@churchyard

Assuming this indeed removes the support for %patchN as was planned, is there a plan to mass fix our packages or let them FTBFS?

Oh, I didn’t see that. Dunno, can we just add a macro file with

%patch0 %{warning: %%patch0 is deprecated…} %patch 0
%patch1 %{warning: %%patch1 is deprecated…} %patch 1
...
%patch9999 %{warning: %%patch9999 is deprecated…} %patch 9999

? Would that work? If it does, I’d do that for compatibility with external packages.

For Fedora packages, some provenpackager will need to run sed over the spec files.

[pmatilai (Panu Matilainen)]

It’s not like this is an unannounced break, rpmbuild been issuing deprecation warnings about that %patchN syntax for over a year now. So maintainers will have had plenty of time to update.

Don’t try creative hacks around this, those packages will just need to be updated now.

Note that for any sort of mass-change, you’d probably want to use %patch -PN instead because that’s 100% backwards compatible to beginning of times. Those who haven’t yet updated to the new syntax might have negleted it because of compatibility concerns.

[ffesti (Florian Festi)]

Good point. I did look at the list of Initiatives but this obviously does not show up there. I’ll add the link to the proposal.

[churchyard (Miro Hrončok)]

I don’t think we should work around the removal.

But I think we need the change owners (or somebody else) to commit to fixing our spec files before we land this.

(I consider the removal to be very unfortunate but I don’t want to fight that fight.)

[gotmax23 (Maxwell G)]

@churchyard

But I think we need the change owners (or somebody else) to commit to fixing our spec files before we land this.

Definitely. I don’t find breaking a thousand packages like this acceptable when the issue can be fixed with one sed invocation.

Earlier this year, I went through all the Go SIG packages and replaced the old %patch<N> invocations with %patch -P<N> (announced in Removing deprecated %patch syntax from go-sig's packages - devel - Fedora Mailing-Lists). I used ~gotmax23/fedora-scripts (main): new_patch_syntax.sh - sourcehut git and ~gotmax23/fedora-scripts (main): go-sig/new_patch_syntax/run.sh - sourcehut git. It’s pretty straightforward; a provenpackager just needs to collect a list of the packages that use the deprecated syntax (by searching through https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz) and then run the script.

[ffesti (Florian Festi)]

I totally agree. This is something we need to manage and get resolved before pushing the alpha into rawhide. We will probably need help from a proven packager and may be some guidance on what’s Fedora’s preferred way of handling this. I am going to update the change page to reflect that.

[mattdm (Matthew Miller)]

@pmatilai

It’s not like this is an unannounced break, rpmbuild been issuing deprecation warnings about that %patchN syntax for over a year now. So maintainers will have had plenty of time to update.

@churchyard, can you quickly see how many of those 1000+ packages have been touched at all by a maintainer in that time? (Not counting the mass rebuilds, of course.)

[churchyard (Miro Hrončok)]

Not trivially. And writing a script to figure that out is more complicated than mass-changing all our spec files.

[pmatilai (Panu Matilainen)]

I did a random sampling of some 30-40 specs still using %patch[01] and none of them were what one could call actively maintained: they generally only had non-maintainer rebuilds, SPDX license updates or C99 fixes in a year or more. I’m sure there are exceptions but I’d say most of these are effectively unmaintained packages.

Most of them would also be better off just using %autosetup instead, but they generally also predate it by several years. Not saying that should be done here (that can’t be reliably automated), just an observation.

As for the break itself, it’s regrettable of couse. Ideally this deprecation would’ve started 15 years ago already, and ran over the course of several years and releases. I lacked the forward vision to do that back then. Now we (relatively!) abruptly found ourselves in this position where the weird hacks to implement this goofy noun/verb syntax is blocking fixes and developments on multiple fronts, and couldn’t really wait for any longer to get this over with.

[ffesti (Florian Festi)]

I added this to both the Scope and the Upgrade/compatibility impact sections. I guess the best way forward it to just have a provenpackager fix them in bulk. Is there any extra procedure needed for this? Like filing another Change request? Writing an announcement on f-d-l? Or can can we get way with just have this written down in the margins of this Change?

Also any provenpackager volunteering?

[kevin (Kevin Fenzi)]

Not volunteering, but I would point out Mass package changes :: Fedora Docs has a process to follow for people who do work on this.

[gotmax23 (Maxwell G)]

If another provenpackager can help here, that is great, but we should definitely sponsor at least one developer on the RPM team into the provenpackager group so they can take care of things like this in the future.

[gtb (Gary Buhrmaster)]

Active team members may come and go, and so may an individuals provenpackager status, so I don’t know that every major infrastructure team needs to be expected to have a provenpackage as a member (that is why provenpackagers are expected to help out other teams and packages in addition to their other contributions), but I would also say that if there is someone on the team who is interested and qualified and willing to take on the additional responsibilities of provenpackager they should certainly consider doing do.

Saying that, I hope that needing things like this (changes in many packages) in the future for RPM continues to be possible, but rare.

[ffesti (Florian Festi)]

I am happy to do the paperwork for the Mass Change as soon as the Change Proposal is approved.

[ffesti (Florian Festi)]

@churchyard Where do you have the number of 1061affected spec files from?

grep -E ‘%patch[[:digit:]]+’ rpm-specs/* | cut -d: -f1 | sort -u | wc -l
1827

grep -E ‘^%patch[[:digit:]]+’ rpm-specs/* | cut -d: -f1 | sort -u | wc -l
1770