Hello. On Tue, 03 Feb 2015 21:32:11 +0100 Christian Boltz wrote:
The advice not to use the %{version} macro in a patch name is still valid, because otherwise you'd have to rename the patch each time the version number changes.
This is clear.
Note that the guidelines doesn't say that you should or should not include the version number in the patch name. It only says that you should avoid using the %{version} macro.
I remember, there was an instruction to name patches versioning. I can't find the source now. "Do NOT use %{version} macro in Patch: line, specify the version by hand." — it looks alternative: either "%{version}" or version [by hand].
What is the right way? I prefer to have a version in a patch name to know that foo-1.2.4-fix_something.patch is applied for "foo = 1.2.4" and, possibly, for "foo > 1.2.4". And it isn't applied for "foo < 1.2.4".
Well, it depends ;-)
Let's say you have a patch that fixes a bug in foo 1.2.4, and that bug is also fixed upstream in the next (not yet available) release. In this case, it makes sense to include the version number in the patch, for example foo-1.2.4-fix-crash.patch so that you can easily spot "outdated" and no longer needed patches.
OTOH, I'd avoid the version number in patches that aren't meant to go upstream (for example some changes in a config file so that it better fits for openSUSE) and will probably stay in the openSUSE package forever. For example, foo-set-packager-to-zypper.patch makes more sense than foo-1.0.1-set-packager-to-zypper.patch which looks a bit strange when the package version number increases.
I'm not sure here. A quick investigation shows: https://build.opensuse.org/package/show/Base:System/at https://build.opensuse.org/package/show/Base:System/bash https://build.opensuse.org/package/show/Base:System/bc https://build.opensuse.org/package/show/Base:System/bluez
Another option is to have a comment line for each patch in the spec,
I totally agree. And this requirement is described in https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Type_1:_minima... -- WBR Kyrill