On Wed, 2020-04-29 at 18:56 +0200, Jan Engelhardt wrote:
On Wednesday 2020-04-29 17:30, Martin Wilck wrote:
And it is also the reason using numbers in filenames for ordering reasons are frowned upon. The only true order is determined by the %patch statements (including those possibly implicitly generated by %autopatch).
It's the filename format used by "git format-patch", and ensures correct ordering of the generated patch files.
Indeed it is -- for git, and any "filesystem" tasks, which is to say, globbing. But that goes out the window the moment one adds PatchN: lines to a .spec file, unfortunate as it may be.
Maybe you can open a feature request at the rpm bug tracker to the effect that, in the future, we could drop all the PatchN: lines and have them implicitly generated from a [0-9]*.patch wildcard. That would align nicely with %autopatch and decriminalize {renames for the sole purpose of reordering}.
Name: Dummy Version: 1.0 Release: 0 Source0: Source.tar.xz %patchlist 0001-Patch-Foo.patch 0002-Patch-Bar.patch 0003-Patch-doSomething.patch %prep %autosetup -p1 %build … Something like that you mean? That's supported since RPM 4.15 (they translate to patch0, patch1 and patch2 here.. so not based on the number in the patch file name, but based on the list it is. Also, I've seen I don't know how many packages where there were multiple 0001-FOO.patch patches; the Number means nothing. People check out master, write the patch, then do format-patch; git always starts numbering at 0001 in this case. Cheers, Dominique