After RPM is before RPM - Changes needed for RPM 4.20 - openSUSE Factory

After RPM is before RPM - Changes needed for RPM 4.20

older
New Tumbleweed snapshot 20240226...

Dominique Leuenberger

20 Feb 2024 20 Feb '24

16:29

Dear Tumbleweed hackers and packagers, It is just a few days ago that Factory was updated to RPM 4.19 (and we are still missing a few fixes for packages requiring user() symbols and not providing them) The next RPM version will come - for sure (if previous release cycles are any indication, RPM 4.20 should be out around September) So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. The preferred way to apply patches are, in order: * %autosetup -p1 * %autosetup -N / %autopatch -p1 * %setup / %patch -P <N> -p 1 (upper case P denotes patch number, lower case is the usual patch -p>num> strip level) * If your package has no patches, best to be prepared for the future and use %autosetup over %setup. Technically, RPM preferred would be %setup / %patch N when not using %autosetup/%autopatch, BUT %patch 1 is only supported properly from RPM 4.18 on, Not behaving as expected on older RPMs, like in Leap 15.x. That's why we switched our packages to the backward compatible form %patch -P 1 I (and some others) have started to go through the openSUSE:Factory packages that apply patches using %patchN (found a total of 2066 packages). About 10% of those have been fixed today with SRs to the development projects. I would appreciate it if you'd take a look at your packages over the next few days/weeks/months and adjust them to use autosetup or, if patches are applied conditionally, use the %patch -P N format. Cheers, Dominique

Show replies by date

Martin Wilck

27 Feb 27 Feb

09:32

On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...

So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already.

I appreciate your efforts, but seeing the massive fallout this has, it looks very much like a thoughtless move of the upstream maintainer. This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work. I fail to see the benefit of deprecating this feature, except that it apparently simplified the implementation of a new feature upstream [1]. Regards Martin [1] https://github.com/rpm-software-management/rpm/pull/2730

Ben Greiner

10:03

...

On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. I appreciate your efforts, but seeing the massive fallout this has, Which fallout? It's only a deprecation warning for now and we have

Am 27.02.24 um 10:32 schrieb Martin Wilck via openSUSE Factory: plenty of time to adjust.

...

it looks very much like a thoughtless move of the upstream maintainer.

You link one of the pull requests yourself. The maintainers gave this some thoughts and even anticipated repercussions. Not thoughtless at all.

...

This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work.

It's a simple automatic find and replace and has been done in the past few days for a couple thousand of packages already. There are far more API changes in various upstream packages which would warrant such a dramatic statement. This one does not.

...

I fail to see the benefit of deprecating this feature, except that it apparently simplified the implementation of a new feature upstream [1].

Reading that PR, it doesn't seem to be just one feature but an effort to modernize the whole codebase.

...

Regards Martin

[1] https://github.com/rpm-software-management/rpm/pull/2730

Martin Wilck

15:03

On Tue, 2024-02-27 at 11:03 +0100, Ben Greiner wrote:

...

Am 27.02.24 um 10:32 schrieb Martin Wilck via openSUSE Factory:

...
On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. I appreciate your efforts, but seeing the massive fallout this has,

...

Which fallout?

Extrapolating from the OBS requests I got for the few packages I am maintaining, there must be hundreds SRs floating around to apply this change to almost every spec, just for openSUSE.

...

> it looks very much like a thoughtless move of the upstream

...
maintainer.

You link one of the pull requests yourself. The maintainers gave this some thoughts and even anticipated repercussions. Not thoughtless at all.

The fact that they considered it makes it worse, not better, in my opinion. They deliberately decided to make their own lives easier and have everybody else deal with it. Yes, it's possible to "adjust" with simple scripting, and no, that doesn't mean it's not a problem.

...

...
This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work.

It's a simple automatic find and replace and has been done in the past few days for a couple thousand of packages already. There are far more API changes in various upstream packages which would warrant such a dramatic statement. This one does not.

Sorry if I sound dramatic. You are right, there's a pattern, and this one is not the worst example. I can't help myself, I find it annoying that people break backward compatibility light-heartedly like this, "because they can". I wish more upstream maintainers took API compatibility as seriously as Linus does. Martin

Dominique Leuenberger

15:14

On Tue, 2024-02-27 at 16:03 +0100, Martin Wilck via openSUSE Factory wrote:

...

Extrapolating from the OBS requests I got for the few packages I am maintaining, there must be hundreds SRs floating around to apply this change to almost every spec, just for openSUSE.

Factory has (had) a total of 2088 packages affected by %patchN on Feb 20 2024 This morning, Factory had 1099 packages affected. Progress is pretty good for something that will only break on us in a year (or half a year, should we really get RPM 4.20 that early into Factory) (I think, taking all pending SRs into account, we are like 80% done with this change)

...

The fact that they considered it makes it worse, not better, in my opinion. They deliberately decided to make their own lives easier and have everybody else deal with it. Yes, it's possible to "adjust" with simple scripting, and no, that doesn't mean it's not a problem.

There are very interesting things on the horizon for RPM/Spec (like dynamic spec generation, doing away with a lot of boilerplate) Just as an example: https://github.com/rpm-software-management/rpm/issues/1087 To not stay in the way of the future, the past sometimes needs to be forgotten.

...

...
...
This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work.

It's a simple automatic find and replace and has been done in the past few days for a couple thousand of packages already. There are far more API changes in various upstream packages which would warrant such a dramatic statement. This one does not.

Sorry if I sound dramatic. You are right, there's a pattern, and this one is not the worst example.

I can't help myself, I find it annoying that people break backward compatibility light-heartedly like this, "because they can". I wish more upstream maintainers took API compatibility as seriously as Linus does.

RIGHT! The kernel is known to not break API /s (the only thing they commit to is user space - but definitively not the kernel API. Ask nVidia :P - or the virtualbox maintainer )

Neal Gompa

15:22

On Tue, Feb 27, 2024 at 10:15 AM Dominique Leuenberger wrote:

...

On Tue, 2024-02-27 at 16:03 +0100, Martin Wilck via openSUSE Factory wrote:

...
Extrapolating from the OBS requests I got for the few packages I am maintaining, there must be hundreds SRs floating around to apply this change to almost every spec, just for openSUSE.

Factory has (had) a total of 2088 packages affected by %patchN on Feb 20 2024

This morning, Factory had 1099 packages affected. Progress is pretty good for something that will only break on us in a year (or half a year, should we really get RPM 4.20 that early into Factory) (I think, taking all pending SRs into account, we are like 80% done with this change)

...
The fact that they considered it makes it worse, not better, in my opinion. They deliberately decided to make their own lives easier and have everybody else deal with it. Yes, it's possible to "adjust" with simple scripting, and no, that doesn't mean it's not a problem.

There are very interesting things on the horizon for RPM/Spec (like dynamic spec generation, doing away with a lot of boilerplate)

Just as an example: https://github.com/rpm-software-management/rpm/issues/1087

To not stay in the way of the future, the past sometimes needs to be forgotten.

We need to get better at incorporating updated stuff then at the lower layers. We're very slow compared to other rolling distributions and non-rolling platforms.

...

...
...
...
This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work.

It's a simple automatic find and replace and has been done in the past few days for a couple thousand of packages already. There are far more API changes in various upstream packages which would warrant such a dramatic statement. This one does not.

Sorry if I sound dramatic. You are right, there's a pattern, and this one is not the worst example.

I can't help myself, I find it annoying that people break backward compatibility light-heartedly like this, "because they can". I wish more upstream maintainers took API compatibility as seriously as Linus does.

RIGHT! The kernel is known to not break API /s (the only thing they commit to is user space - but definitively not the kernel API. Ask nVidia :P - or the virtualbox maintainer )

The kernel breaks the userspace API too. It happens, and most of the time nobody cares. The syscall interface is the only thing that's actually protected. Everything else is not. -- 真実はいつも一つ！/ Always, there's only one truth!

Martin Wilck

16:42

On Tue, 2024-02-27 at 16:14 +0100, Dominique Leuenberger wrote:

...

Factory has (had) a total of 2088 packages affected by %patchN on Feb 20 2024

This morning, Factory had 1099 packages affected. Progress is pretty good for something that will only break on us in a year (or half a year, should we really get RPM 4.20 that early into Factory) (I think, taking all pending SRs into account, we are like 80% done with this change)

As I said in my first post in this thread, I appreciate the work you're doing.

...

There are very interesting things on the horizon for RPM/Spec (like dynamic spec generation, doing away with a lot of boilerplate)

Just as an example: https://github.com/rpm-software-management/rpm/issues/1087

Interesting? Certainly. Will it make package maintainers' lives easier? No, at least not in the foreseeable future for anyone who has to maintain compatibility for LTS releases like SLE.

...

To not stay in the way of the future, the past sometimes needs to be forgotten.

I still fail to see why this breakage was necessary to enable future enhancements.

...

...
I can't help myself, I find it annoying that people break backward compatibility light-heartedly like this, "because they can". I wish more upstream maintainers took API compatibility as seriously as Linus does.

RIGHT! The kernel is known to not break API /s (the only thing they commit to is user space - but definitively not the kernel API. Ask nVidia :P - or the virtualbox maintainer )

I think you understood well that I was referring to the user space API, not kernel-internal APIs. Support for basic macros is an external API as far as rpm is concerned. Regards, Martin

Björn Bidar

10:05

Martin Wilck via openSUSE Factory writes:

...

On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already.

I appreciate your efforts, but seeing the massive fallout this has, it looks very much like a thoughtless move of the upstream maintainer. This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work.

It does sound like quite fast change IMHO. The warning should have been added at least a few versions earlier. From my point of the upstream rpm was often very Redhat/Fedora focused, such a quick change without a longer warning follows that manner in my opinion.

Ben Greiner

10:14

Am 27.02.24 um 11:05 schrieb Björn Bidar:

...

Martin Wilck via openSUSE Factory writes:

...
On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. I appreciate your efforts, but seeing the massive fallout this has, it looks very much like a thoughtless move of the upstream maintainer. This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work. It does sound like quite fast change IMHO. The warning should have been added at least a few versions earlier.

...
From my point of the upstream rpm was often very Redhat/Fedora focused, such a quick change without a longer warning follows that manner in my opinion.

There has been one year between the upstream releases of 4.18 and 4.19 [1]. RPM 4.19 came out in 2023Q3. RPM 4.20 is projected to come out in 2024Q3 [2]. Even the ever fast rolling Tumbleweed took some time to adopt 4.19 [3]. Extrapolating this to 4.20, you now have almost a year to fix your specfile. For a rolling release distro, this is not a fast change. - Ben [1] https://github.com/rpm-software-management/rpm/tags [2] https://rpm.org/roadmap.html [3] https://build.opensuse.org/request/show/1132932

Fridrich Strba

11:36

On 27/02/2024 11:14, Ben Greiner wrote:

...

Extrapolating this to 4.20, you now have almost a year to fix your specfile. For a rolling release distro, this is not a fast change.

Besides the fact that a simple sed -i "/^%patch[0-9]/ s/^%patch/%patch -P /g" *.spec does the thing just right. Provided that spec-cleaner is fixed not to revert that change :) We did it on those ~800 packages in Java:packages in something like 1 afternoon and 1 following morning. Cheers F.

Ludwig Nussel

11:51

Fridrich Strba via openSUSE Factory wrote:

...

On 27/02/2024 11:14, Ben Greiner wrote:

...
Extrapolating this to 4.20, you now have almost a year to fix your specfile. For a rolling release distro, this is not a fast change.

Besides the fact that a simple

sed -i "/^%patch[0-9]/ s/^%patch/%patch -P /g" *.spec

does the thing just right. Provided that spec-cleaner is fixed not to revert that change :)

We did it on those ~800 packages in Java:packages in something like 1 afternoon and 1 following morning.

Still pretty annoying. With the alternative syntax '*' in vim doesn't work. Packages should be switched to %autosetup or %autopatch instead IMO. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg)

Neal Gompa

11:59

On Tue, Feb 27, 2024 at 5:14 AM Ben Greiner wrote:

...

Am 27.02.24 um 11:05 schrieb Björn Bidar:

...
Martin Wilck via openSUSE Factory writes:

...
On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. I appreciate your efforts, but seeing the massive fallout this has, it looks very much like a thoughtless move of the upstream maintainer. This syntax has been supported for more than 25 years, and while it has always been kind of strange, it's easy to remember and widely used. By deprecating this syntax, they are causing hundreds of maintainers pointless work. It does sound like quite fast change IMHO. The warning should have been added at least a few versions earlier.

...
From my point of the upstream rpm was often very Redhat/Fedora focused, such a quick change without a longer warning follows that manner in my opinion.

There has been one year between the upstream releases of 4.18 and 4.19 [1]. RPM 4.19 came out in 2023Q3. RPM 4.20 is projected to come out in 2024Q3 [2]. Even the ever fast rolling Tumbleweed took some time to adopt 4.19 [3].

Extrapolating this to 4.20, you now have almost a year to fix your specfile. For a rolling release distro, this is not a fast change.

- Ben

[1] https://github.com/rpm-software-management/rpm/tags [2] https://rpm.org/roadmap.html [3] https://build.opensuse.org/request/show/1132932

To the point about upstream rpm being "Red Hat/Fedora focused", this is actually our fault in openSUSE. The openSUSE RPM maintainers do not participate as much as I would like, and have historically patched RPM to kingdom come. This also has made adopting new RPM versions hard. (The situation around rpm's patch load in openSUSE is much higher than I would like it to be still...) I participate in RPM upstream mostly to support non-RH rpm usage, particularly as someone who helps maintain RPM in Mageia, OpenMandriva, and at one point working on RPM on macOS. They don't prevent me from being represented there. It's really a matter of wanting to show up and engage productively. As an aside, RPM has warned about this since 4.18, and nobody noticed? RPM 4.18 entered Factory near Christmas 2022: https://code.opensuse.org/package/rpm/c/e0a517c3a535feeec345f19d1d3fdd19b59c... -- 真実はいつも一つ！/ Always, there's only one truth!

Ben Greiner

12:36

Am 27.02.24 um 12:59 schrieb Neal Gompa:

...

On Tue, Feb 27, 2024 at 5:14 AM Ben Greiner wrote:

...
Am 27.02.24 um 11:05 schrieb Björn Bidar:

...
Martin Wilck via openSUSE Factory writes:

...
On Tue, 2024-02-20 at 17:29 +0100, Dominique Leuenberger wrote:

...
So far we have come across one change that will impact a log of packages: RPM 4.20 will no longer support %patchN (e.g %patch0); RPM 4.19 has warned about this during the build already. As an aside, RPM has warned about this since 4.18, and nobody noticed? RPM 4.18 entered Factory near Christmas 2022: https://code.opensuse.org/package/rpm/c/e0a517c3a535feeec345f19d1d3fdd19b59c...

Not completely true. The first introduction of the warning message I could find was PR #2352 from January 2023. The first release of this and a bunch of corrections and cleanups afterwards which made it into Tumbleweed is 4.19. Which is not even a month old in Tumbleweed. Since then we get this deprecation warning and are already discussing it. The backport to 4.18.1 as part of PR #2406 was never submitted to Tumbleweed. - Ben [PR #2352] https://github.com/rpm-software-management/rpm/pull/2352 [PR #2406] https://github.com/rpm-software-management/rpm/pull/2406

Age (days ago)

Last active (days ago)

List overview

Download

12 comments

7 participants

participants (7)

Ben Greiner
Björn Bidar
Dominique Leuenberger
Fridrich Strba
Ludwig Nussel
Martin Wilck
Neal Gompa