Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
If anyone has any objections or would like to exclude a package, please let me know.
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
This is the change with the highest compatibility (back to RPM 3.x). There are more modern options (like %autosetup) that packagers are encouraged to use but are out of scope here.
Florian
[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://fedoraproject.org/wiki/Changes/RPM-4.20 [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt [5] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt
Dne 06. 05. 24 v 1:56 odp. Florian Festi napsal(a):
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
Packages maintained by Tito will be affected by this. But only builds that uses DistributionBuilder or UpstreamBuilder builder. Afaik no packages that goes to Fedora uses this so it should not affect any Fedora maintainer.
Adding link to issue I just created for reference: https://github.com/rpm-software-management/tito/issues/499
And thank you for doing this change.
Am 06.05.24 um 13:56 schrieb Florian Festi:
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?
On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel devel@lists.fedoraproject.org wrote:
Am 06.05.24 um 13:56 schrieb Florian Festi:
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?
Yes. It's been supported for a very long time.
Neal Gompa wrote:
On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel devel@lists.fedoraproject.org wrote:
Am 06.05.24 um 13:56 schrieb Florian Festi:
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?
Yes. It's been supported for a very long time.
%patch -P is already documented in the 1997 First Edition of Maximum RPM. Here is the link in the 2000 online edition: https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSI...
Kevin Kofler
Am 08.05.24 um 00:22 schrieb Kevin Kofler via devel:
Neal Gompa wrote:
On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel devel@lists.fedoraproject.org wrote:
Am 06.05.24 um 13:56 schrieb Florian Festi:
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?
Yes. It's been supported for a very long time.
%patch -P is already documented in the 1997 First Edition of Maximum RPM. Here is the link in the 2000 online edition: https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSI...
Ok. I got it :-)
Hi,
Florian Festi ffesti@redhat.com writes:
If anyone has any objections or would like to exclude a package, please let me know.
Could you please exclude the .NET packages (dotnet6.0, dotnet7.0, dotnet8.0)? dotnet8.0 shouldn't need a fix (and it doesn't appear in your list). dotnet7.0 is already EOL/orphaned/retired. dotnet6.0 will go through the same EOL/orphan/retiring process later this year. There's little point changing it now.
Thanks!
Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
On 5/8/24 00:49, Omair Majid wrote:
Hi,
Florian Festi ffesti@redhat.com writes:
If anyone has any objections or would like to exclude a package, please let me know.
Could you please exclude the .NET packages (dotnet6.0, dotnet7.0, dotnet8.0)? dotnet8.0 shouldn't need a fix (and it doesn't appear in your list). dotnet7.0 is already EOL/orphaned/retired. dotnet6.0 will go through the same EOL/orphan/retiring process later this year. There's little point changing it now
Sure!
Florian
I'd actually prefer the `%patch 1` syntax (which is also the first on the list [1]). Yes, I understand that `%patch -P1` is to stay on the safe side, but this is Fedora change, not RHEL or EPEL change.
But if you insist on `-P1`, then please skip all packages I am associated with. I'd prefer to have them broken and if needed, I fix them later myself.
Vít
Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
If anyone has any objections or would like to exclude a package, please let me know.
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
This is the change with the highest compatibility (back to RPM 3.x). There are more modern options (like %autosetup) that packagers are encouraged to use but are out of scope here.
Florian
[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://fedoraproject.org/wiki/Changes/RPM-4.20 [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt [5] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 5/10/24 14:10, Vít Ondruch wrote:
I'd actually prefer the `%patch 1` syntax (which is also the first on the list [1]). Yes, I understand that `%patch -P1` is to stay on the safe side, but this is Fedora change, not RHEL or EPEL change.
But if you insist on `-P1`, then please skip all packages I am associated with. I'd prefer to have them broken and if needed, I fix them later myself.
We have an even easier solution for you: You can just run the script at [3] with -n on your own spec files to get them changed to the %patch N variant. If you do that right now they will not break nor will they be touched during the mass change.
As I said the %patch -PN syntax is the one with the best compatibility - reaching back into the dark ages. I am not advocating for people to use it. Anyone is free and encouraged to move to something more modern - before or after the change. We are using this variant so spec files continue to work on older distributions and the chance of breakage is minimized. This way packagers that don't care don't have to.
Florian
Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
If anyone has any objections or would like to exclude a package, please let me know.
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
This is the change with the highest compatibility (back to RPM 3.x). There are more modern options (like %autosetup) that packagers are encouraged to use but are out of scope here.
Florian
[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://fedoraproject.org/wiki/Changes/RPM-4.20 [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt [5] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Florian Festi wrote:
We have an even easier solution for you: You can just run the script at [3] with -n on your own spec files to get them changed to the %patch N variant. If you do that right now they will not break nor will they be touched during the mass change.
As I said the %patch -PN syntax is the one with the best compatibility - reaching back into the dark ages. I am not advocating for people to use it. Anyone is free and encouraged to move to something more modern - before or after the change. We are using this variant so spec files continue to work on older distributions and the chance of breakage is minimized. This way packagers that don't care don't have to.
What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped.
Kevin Kofler
On Sat, 2024-05-11 at 01:04 +0200, Kevin Kofler via devel wrote:
Florian Festi wrote:
We have an even easier solution for you: You can just run the script at [3] with -n on your own spec files to get them changed to the %patch N variant. If you do that right now they will not break nor will they be touched during the mass change.
As I said the %patch -PN syntax is the one with the best compatibility - reaching back into the dark ages. I am not advocating for people to use it. Anyone is free and encouraged to move to something more modern - before or after the change. We are using this variant so spec files continue to work on older distributions and the chance of breakage is minimized. This way packagers that don't care don't have to.
What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped.
The shortest syntax is just to use Patch: foo.patch , and %autosetup . Much easier on merge requests, too.
Adam Williamson wrote:
The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly applies all patches in numeric order. Cannot reorder patches, cannot apply them conditionally (e.g., based on the 0%{?fedora} version), cannot specify a -b backup file extension for each patch. So it is not a fair comparison.
Kevin Kofler
On 5/11/24 01:04, Kevin Kofler via devel wrote:
Florian Festi wrote:
We have an even easier solution for you: You can just run the script at [3] with -n on your own spec files to get them changed to the %patch N variant. If you do that right now they will not break nor will they be touched during the mass change.
As I said the %patch -PN syntax is the one with the best compatibility - reaching back into the dark ages. I am not advocating for people to use it. Anyone is free and encouraged to move to something more modern - before or after the change. We are using this variant so spec files continue to work on older distributions and the chance of breakage is minimized. This way packagers that don't care don't have to.
What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped.
I am glad you asked.
The short answer is the %patchN instances are not a proper macros and we no longer can have that.
The long story is that the spec parsing code is old, weird and is one of the few places in RPM that have not seen major renovations in the last two decades - until now. We have also put a lot more stress on that code with all the language specific macros and lua scripts, extended debuginfo support, dynamic spec parts, the new build scripts, ... So a lot of the weirdness and corner cases that were "fine" for "normal" specs are now showing up more and more.
Expanding the %patchN syntax required a whole separate parse and expand run that was separate from the macro expansion. This led to subtle semantic issues wrt expansion order. It also made %prep special and %patchN only worked in there. %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
This is only one of many issue with the parsing (and building) code and we are actively working on disentangling the mess. For most things packager won't notice unless they do more complicated things where these semantic details matter. But the %patchN syntax is something that is just not worth preserving. It does not fit into the overall macro frame work and should not have been added in the first place. I also have a hard time seeing how adding a single space per %patch line is overburdening packagers.
Florian
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
Vít
On 5/13/24 16:09, Vít Ondruch wrote:
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
- Panu -
Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):
On 5/13/24 16:09, Vít Ondruch wrote:
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues.
I have no hopes convincing you. But thank you for clarification.
Vít
- Panu -
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, May 13, 2024 at 10:09 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):
On 5/13/24 16:09, Vít Ondruch wrote:
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues.
I have no hopes convincing you. But thank you for clarification.
This last statement was unnecessarily hostile. You are better than that, Vit.
I assume that Panu's statement above - "that's the only place where they make sense" - was an unintentional overstatement and should have been read as "that's the only place we could think of where it made sense". You've now provided a reasonable argument for why %check might make sense.
To expand on your example a bit, what I think you're saying is that in the case of Ruby, we ship not only the binary bits but also the Ruby tests in the RPMs. For sensible reasons, we want to deliver those unmodified from upstream, but we also want to be able to run them in the %check section which necessitates making some modifications due to the limitations and restrictions present in the Koji build system. By being able to constrain the patch application to the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs) means that we can package the unmodified sources without having to resort to custom trickery in the specfile (copying all the tests to a new location to modify them before running or some such). Is that a fair restatement of your use-case, Vit?
Stephen Gallagher wrote:
the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs)
No, it runs after %install but before the files are packaged up. It's possible for %check to make changes to what was staged in %install and have those changes appear in the package. I think removing that ability would be an improvement, but that's how it currently is.
Any changes made by %check outside of %{buildroot} should not affect the binary package though.
Björn Persson
Dne 14. 05. 24 v 2:03 Stephen Gallagher napsal(a):
On Mon, May 13, 2024 at 10:09 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):
On 5/13/24 16:09, Vít Ondruch wrote:
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues.
I have no hopes convincing you. But thank you for clarification.
This last statement was unnecessarily hostile. You are better than that, Vit.
Sorry. What I wanted is just to explain some context and somehow said that while I would like have this possibility, I am not e.g. going to open upstream RFE ticket.
I assume that Panu's statement above - "that's the only place where they make sense" - was an unintentional overstatement and should have been read as "that's the only place we could think of where it made sense". You've now provided a reasonable argument for why %check might make sense.
To expand on your example a bit, what I think you're saying is that in the case of Ruby, we ship not only the binary bits but also the Ruby tests in the RPMs. For sensible reasons, we want to deliver those unmodified from upstream, but we also want to be able to run them in the %check section which necessitates making some modifications due to the limitations and restrictions present in the Koji build system. By being able to constrain the patch application to the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs) means that we can package the unmodified sources without having to resort to custom trickery in the specfile (copying all the tests to a new location to modify them before running or some such). Is that a fair restatement of your use-case, Vit?
Right, that is fair.
Thank you for taking time to make sure my use case is properly understood. Appreciate that.
Vít
Vít Ondruch vondruch@redhat.com wrote:
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues.
I have no hopes convincing you. But thank you for clarification.
This feels like the tests should be patched (and these patches upstreamed) to behave differently depending on some option, and the spec file should then use this option to trigger the correct one. I don't know enough about Ruby to suggest The Way™ to pass this option; but usually environment variables will do. (Other test suites have tags that can be used to select tests that should (not) be run which might be another (upstreamable) solution.)
Tim
Dne 14. 05. 24 v 11:26 Tim Landscheidt napsal(a):
Vít Ondruch vondruch@redhat.com wrote:
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues. I have no hopes convincing you. But thank you for clarification.
This feels like the tests should be patched (and these patches upstreamed) to behave differently depending on some option
I don't disagree. I am all for upstreaming. But there are more pros and cons.
Vít
, and the spec file should then use this option to trigger the correct one. I don't know enough about Ruby to suggest The Way™ to pass this option; but usually environment variables will do. (Other test suites have tags that can be used to select tests that should (not) be run which might be another (upstreamable) solution.)
Tim
On 5/13/24 17:08, Vít Ondruch wrote:
Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):
On 5/13/24 16:09, Vít Ondruch wrote:
Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.
Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?
No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.
Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues.
The rpm model is simply that all source preparation is done in %prep, and everything is build around that design. There's no way to enforce that, but things like having %setup and %patch only available there are pretty strong hints at how it wants to be used.
I would make a copy of the tests for running purposes and patch that, all in %prep. That way you can also use %autosetup for it all. There will always be special circumstances, but on principle %patch should be considered a legacy construct. Packagers shouldn't have to be bothering with individual patch applications like that.
- Panu -
Dne 10. 05. 24 v 15:20 Florian Festi napsal(a):
On 5/10/24 14:10, Vít Ondruch wrote:
I'd actually prefer the `%patch 1` syntax (which is also the first on the list [1]). Yes, I understand that `%patch -P1` is to stay on the safe side, but this is Fedora change, not RHEL or EPEL change.
But if you insist on `-P1`, then please skip all packages I am associated with. I'd prefer to have them broken and if needed, I fix them later myself.
We have an even easier solution for you: You can just run the script at [3] with -n on your own spec files to get them changed to the %patch N variant. If you do that right now they will not break nor will they be touched during the mass change.
This is not easier, because it needs action "right now", while I'd like to take action when time permits (or when really needed, FTBFS is not end of the world after all). Of course I'd be more then happy if you can run your script with `-n` option on my packages right now.
Thank you
Vít
As I said the %patch -PN syntax is the one with the best compatibility - reaching back into the dark ages. I am not advocating for people to use it. Anyone is free and encouraged to move to something more modern - before or after the change. We are using this variant so spec files continue to work on older distributions and the chance of breakage is minimized. This way packagers that don't care don't have to.
Florian
Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):
Hi everyone,
RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now.
There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change:
%patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2
If anyone has any objections or would like to exclude a package, please let me know.
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
This is the change with the highest compatibility (back to RPM 3.x). There are more modern options (like %autosetup) that packagers are encouraged to use but are out of scope here.
Florian
[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://fedoraproject.org/wiki/Changes/RPM-4.20 [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt [5] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, 2024-05-06 at 13:56 +0200, Florian Festi wrote:
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
I think you should rebuild the packages because at the moment , koschei [1] is saying that all that 1800 packages are FTBFS
[1] https://koschei.fedoraproject.org/
Best regards,
Dne 11. 06. 24 v 0:38 Sérgio Basto napsal(a):
On Mon, 2024-05-06 at 13:56 +0200, Florian Festi wrote:
As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM.
I think you should rebuild the packages because at the moment , koschei [1] is saying that all that 1800 packages are FTBFS
BTW once the commits are in, any packager can trigger rebuild. No proven packager needed anymore.
Vít
[1] https://koschei.fedoraproject.org/
Best regards,
-
Adam Williamson -
Björn Persson -
Florian Festi -
Kevin Kofler -
Leon Fauster -
Miroslav Suchý -
Neal Gompa -
Omair Majid -
Panu Matilainen -
Stephen Gallagher -
Sérgio Basto -
Tim Landscheidt -
Vít Ondruch